アプリ版:「スタンプのみでお礼する」機能のリリースについて

掲題の件について質問させて下さい。

NAPTでのポート番号変換を、現実的にはどう整合性をつけているのかが分かりません。
NAPT側で付与されるLAN内の端末ごとに振っているポート番号が、実際に通信で使用されるべきポート番号と異なる点について、それで通信可能であるのか、可能であるならどうやって通信を確立しているのか、と言う点に疑問を憶えています。

例えば、LAN内において、接続しているPCがAとBの2台あり、プライベートIPをそれぞれ持っていたとして、https通信で外部の同一のウェブサーバーに接続したとします。
NAPTが機能していると、サーバーからは同じIPアドレスだが、ポート番号が異なるリクエストが2つ来たと言う形で応答しますよね。

その場合、本来LAN内のPCからはAとBの両方、443番(https)のポート番号で接続しに行き、443番での返信を待つことなると思うのですが、NAPTが機能していれば、AとBの両方が、送信元の使用ポートは、サーバー側から見ればポート番号443を使用していない状態になると思うのです。

そうした時、サーバーからPCに向けたhttps通信はhttps通信でありながら、送信元ポート番号(サーバーがpcに対して返信をすべきポート番号)は443を使用していないことになります。
インターネット通信においては、送信者受信者ともに同じポート番号を使用する、また、通信においては、その通信の種別ごとに使用するポートについて、指定のもの(https通信であれば443)を使用するという前提で憶えていたのですが、こうした受領側のポート番号は通信の与件には必須ではないのでしょうか。
簡単に例を書くと、PCのAとB、NAPTをするLANの外向けグローバルIPを次のように規定した時:
PCA:192.168.1.2(NAPT変換時はポート番号100を付与)
PCB:192.168.1.3(NAPT変換時はポート番号200を付与)
グローバルIP:32.32.32.32
サーバーIP:64.64.64.64

PCAからウェブサーバーに対してhttpsで接続:
 192.168.1.2:443→32.32.32.32:100にして、64.64.64.64:443向けに発信
PCBからウェブサーバーに対してhttpsで接続:
 192.168.1.3:443→32.32.32.32:200にして、64.64.64.64:443向けに発信

になると、そのリクエストに対するサーバーからの返信は、https通信なのにも関わらず、
443宛てではなく、100、200宛ての通信を返信することになるということです。
こういう通信が許されているのか、あるいは別の方法で回避しているのかが分かりません。

サーバー側は通信を受領する時、「この通信はNAPT変換されていて、本当は443からの発信であるから、443を想定したhttps通信にして100、200のポート向けに返信しよう」と言うような具合で解釈してくれているのでしょうか。

また、サーバーから通信を受領する側のPCのAとBは、https通信を受領するので、こちらも443ポートを開けて待ち構えていないといけないと思うのですが、この443のポート番号指定はサーバー側は意識することなく、NAPT側がサーバーからの送信を受領し、LAN向けに通信を変換する時に勝手につけているものなのでしょうか。


ややこしい話なのですが、一部分でも教えて頂ける方がいらっしゃいましたら、ご教示お願いいたします。

A 回答 (5件)

>IPパケットのSRC-PORTとDST-PORTは送信元ポートと宛先ポートだと思うのですが、この両者は異なっても良いのでしょうか。



問題ありません。
送信側のポート番号は任意に選択できます。

もし、送信元ポート番号も固定となった場合、Webブラウザでどこかのページを見ていたとき、画像がてんこ盛りなページだった場合にページの表示完了までに時間がかかります。
画像一つずつしか取得できませんから。
また、ブラウザ内の別のタブで同じサイトのページを見る。という場合にも制限がかかってしまいます。
# よほどの低速回線でもなければ人間が読むより通信完了のほうが早いですが。

>そうするとhttpsは443番のポートを使うんだよというルールが崩れてしまうように思うのです。

「サーバ側で待ち受けするポート番号」は固定になります。
そうしないとクライアント側がどのポート番号宛てに接続要求を出すのかが決定できません。
# ただし、セキュリティ対策などで意図的にポート番号を変えている場合はあります。
# その場合は、クライアント側もそのポート番号を指定して接続することになります。
# 例えば…sshを標準ポートのままだと乗っ取りの試行の接続が多くなるので別のポート番号に変更する…とか。

FTPのデータコネクションなどのようにサーバ側クライアント側に対して接続要求するものも極まれにあったりします。
適切に設定しないとルータ越えできなかったりしますけどね。


「送信元ポート番号 ランダム」で検索すると以下のようなページが見つかります。
http://www5e.biglobe.ne.jp/%257eaji/3min/43.html
http://win.kororo.jp/archi/tcp_ip/port.php


んで、NAPTのほうは…適当に検索すると画像で説明しているページなんかも見つかるでしょう。
https://xtech.nikkei.com/it/atcl/column/17/01190 …
とか
https://itsakura.com/network-nat-napt
とか。
# 後者はルータ内のPCのIPアドレスが192.168.2.1と192.168.3.1となっているので、ネットマスクが一般的なブロードバンドルータで使われる255.2552.255.0ではないのが…微妙ですけど。
    • good
    • 0
この回答へのお礼

御礼遅れてすみません。
回答ありがとうございました! 
なるほどー! すっきりしました。
詳しい回答頂きありがとうございます。

お礼日時:2021/04/08 23:43

>IPパケットのSRC-PORTとDST-PORTは送信元ポートと宛先ポートだと思うのですが、この両者は異なっても良いのでしょうか。



良いというより、普通。昔はDNSがSRC-PORTもDST-PORTも、慣用的に53/udpだった。

>httpsは443番のポートを使うんだよというルールが崩れてしまうように思うのです。

httpsサーバが口を空けて待っているのは443/tcp、なのでクライアント発の通信はDST-PORT=443、サーバ発の応答はSRC-PORT=443になる。
    • good
    • 0
この回答へのお礼

御礼遅れてすみません。
回答ありがとうございました! 
通信の内容種別で、NAPT変換後の送信元ポート番号はそれにしばられないということですね。

お礼日時:2021/04/08 23:42

NAPTは、ソースアドレスをWAN側のIPの書き換えて、ソースポート番号をNAPT装置が管理するポート番号に書き換える仕事です。

もちろん、NAPT装置が管理するポート番号をどこのソースアドレスのノードにマップしたのかは記録し、戻り通信はその反対を行います。

LAN側から下記のパケットが来たとします。SRC-PORT=2000はSRC-IP=Aの機器が決めたもの、SRC-PORT=3000はSRC-IP=Bの機器が決めたものです。AとBで調停しないのでSRC-PORTは同じになってしまうこともありえます。

①SRC-IP=A、DST-IP=Z、SRC-PORT=2000、DST-PORT=443
②SRC-IP=B、DST-IP=Z、SRC-PORT=3000、DST-PORT=443

NATデバイスを通過すると各パケットは以下になります。YはNATデバイスのWAN側IP。SRC-PORTはNATデバイスが管理するポート番号に変わります。

①SRC-IP=Y、DST-IP=Z、SRC-PORT=5000、DST-PORT=443
②SRC-IP=Y、DST-IP=Z、SRC-PORT=5001、DST-PORT=443

NATデバイスは、自分が割り当てたSRC-PORTと、元SRC-IPの対応テーブルを内部に持ちます。

①、②の通信の戻りは以下になります。

①SRC-IP=Z、DST-IP=Y、SRC-PORT=443、DST-PORT=5000
②SRC-IP=Z、DST-IP=Y、SRC-PORT=443、DST-PORT=5001

NATデバイスは「自分が割り当てたSRC-PORTと、元SRC-IPの対応」を覚えているので、そのルールで変換します。

①SRC-IP=Z、DST-IP=A、SRC-PORT=443、DST-PORT=5000
②SRC-IP=Z、DST-IP=B、SRC-PORT=443、DST-PORT=5001

NAPTを使うとSRC-PORT番号プールはLAN側の全ノードでシェアされますので、えらい勢いで浪費され、サイクリックに使用されます。勢いは新規セション数だとかLAN側ノード数に相関性を示します。

Transix(DS-LITE)なんかですとVNE側でNAPTをします。複数顧客でグローバルv4アドレスをシェアすると、とんでもないことになりそうです。
    • good
    • 0
この回答へのお礼

回答ありがとうございます! 
お礼遅れて申し訳ありません。

無知で恐縮なのですが教えて下さい。

IPパケットのSRC-PORTとDST-PORTは送信元ポートと宛先ポートだと思うのですが、この両者は異なっても良いのでしょうか。No.1、No.2の人からそう提示して頂いて一旦納得したのですが、そうするとhttpsは443番のポートを使うんだよというルールが崩れてしまうように思うのです。これってその辺りのルールとnaptで変換されているポートの整合性はどのようにつけているのか分かりますでしょうか?

お礼日時:2021/04/03 23:39

>https通信を受領するので、こちらも443ポートを開けて待ち構えていないといけない



netstat -naすればわかりますが、PC側は「192.168.1.2:443」とはならず「192.168.1.2:60652」のようにポート番号が動的に割り当てられます。
https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%95 …

NAPTは内側からの「PC:動的ポート番号ーサーバ:443」のTCPパケットを受け取って覚えておくことでNAT変換時の戻り先を決めてます。

サーバー側は絡みません。
    • good
    • 0
この回答へのお礼

No.1さんの御礼に殆ど書いてしまいましたが、本件回答ありがとうございました!
サーバー側は絡まないんですね。

お礼日時:2021/03/31 00:46

WireSharkなどのパケットキャプチャで見た方が早いんですが…。



>PCA:192.168.1.2(NAPT変換時はポート番号100を付与)
>PCB:192.168.1.3(NAPT変換時はポート番号200を付与)
>グローバルIP:32.32.32.32
>サーバーIP:64.64.64.64
これに、ルータの192.168.1.1が加わって…

>PCAからウェブサーバーに対してhttpsで接続:
送信IPとポートが192.268.1.2:30000(接続毎に変わる)、接続先IPとポートが64.64.64.64:443のパケットを、192.168.1.1のルータ(デフォルトゲートウェイ)へなげる。
 ルータは送信元ポート30000のパケットの送信元IPを記憶して、32.32.32.32:30000を送信元に書き換えて次のルータへなげる。
 サーバは32.32.32.32:30000の送信元から来たパケットを受け入れて、レスポンスを送信す。。その際の送信元IPとポートは64.64.64.64:443で送信先IPとポートは32.32.32.32:30000。
 ルータはレスポンスのパケットを受け取り、送信元IPとポート番号からPCAの30000ポートへの返信としてパケットを転送する。

PCBからのパケットも同様に処理します。
ルータが送信元IPを書き換える時、既にほかの通信で使用中のポート番号とカブる場合は送信元ポート番号も書き換えて投げるでしょう。
    • good
    • 0
この回答へのお礼

なるほど!
詳しく書いて頂きありがとうございました!

私の納得ポイントは、
1.https通信では443と指定されていたので、その通信種別ごとに決まったポートを使用しなければいけないと思っていたが、別にそれを使用しなくとも良い。通信種別ごとのポートは指定のものを使用しなくて良い。
2.NAPT機能のエフェメラルポート割当によってルーターが勝手にポート番号を割り振り、変換し、記憶し、サーバーからの返信時にそれを再度変換する。
と言う形でした。

お礼日時:2021/03/31 00:45

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!