☰

要約

tag-icon • tag-icon ubuntu networking tcp port-forwarding socket
要約

を実行していますUbuntu server 22.04が、ローカル マシンでポート転送に関する奇妙な問題が発生しています。このマシンには 2 つの Ethernet インターフェイスがあり、接続されたenp1s0インターフェイスには IP アドレス があります192.168.1.50。完全な IP 構成は次のとおりです。

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e0:4f:68:02:bb brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.50/24 metric 100 brd 192.168.1.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 240f:74:de92::d1e/128 scope global dynamic noprefixroute 
       valid_lft 35597sec preferred_lft 35597sec
    inet6 fd41:d8b6:99ba::d1e/128 scope global dynamic noprefixroute 
       valid_lft 35597sec preferred_lft 35597sec
    inet6 fd41:d8b6:99ba:0:2e0:4fff:fe68:2bb/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 240f:74:de92:0:2e0:4fff:fe68:2bb/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 98462sec preferred_lft 98462sec
    inet6 fe80::2e0:4fff:fe68:2bb/64 scope link 
       valid_lft forever preferred_lft forever
3: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:e0:4c:68:01:6e brd ff:ff:ff:ff:ff:ff
    altname enp2s0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:55:86:e6:e5 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

ルーターのポート転送ルールを設定して、TCPまたはUDPパケットfrom wan to port 22211がforwarded to lan 192.168.1.50 port 22211

私の設定ではufw、このポートのルーティングを許可しています。

$ sudo ufw status
[sudo] password for *
Status: active

To                         Action      From
--                         ------      ----
22211/tcp                  ALLOW       Anywhere                  
22211/tcp (v6)             ALLOW       Anywhere (v6)

ここで、このポートに対して単純な netcat ソケット ( ) を開始すると、ローカル ネットワーク内の別のマシン経由で問題なくnc -l -p 22211アクセスできます。別のローカル マシンから telnet したときのログを以下に示します。接続して、メールを送信し、Enter キーを押します。telnettcudumpa

$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:01:48.350024 IP (tos 0x0, ttl 64, id 59572, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.196.38840 > 192.168.1.50.22211: Flags [S], cksum 0x527d (correct), seq 3440167578, win 32120, options [mss 1460,sackOK,TS val 3772353734 ecr 0,nop,wscale 7], length 0
21:01:48.350139 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.50.22211 > 192.168.1.196.38840: Flags [S.], cksum 0x3a60 (correct), seq 495600843, ack 3440167579, win 65160, options [mss 1460,sackOK,TS val 102903428 ecr 3772353734,nop,wscale 7], length 0
21:01:48.351892 IP (tos 0x0, ttl 64, id 59573, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.196.38840 > 192.168.1.50.22211: Flags [.], cksum 0x66b7 (correct), seq 1, ack 1, win 251, options [nop,nop,TS val 3772353737 ecr 102903428], length 0
21:01:50.698846 IP (tos 0x0, ttl 64, id 59574, offset 0, flags [DF], proto TCP (6), length 55)
    192.168.1.196.38840 > 192.168.1.50.22211: Flags [P.], cksum 0xf275 (correct), seq 1:4, ack 1, win 251, options [nop,nop,TS val 3772356082 ecr 102903428], length 3

しかし、ローカル ネットワークの外部から Telnet フォームを試みると、何らかの理由で接続が確立されません。長い間、ポート転送設定がオフになっていると確信していました (同じルーターがローカル ネットワーク内の別のマシンに他のポートを転送するのは問題なく、基本的に設定を別のポートにミラ​​ーリングしただけです)。しかし、tcpdump以下のログからわかるように、パケットはインターフェイスに到着しますenp1s0。

$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:58:05.448829 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x4448 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560510789 ecr 0,sackOK,eol], length 0
20:58:06.593532 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x405f (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560511790 ecr 0,sackOK,eol], length 0
20:58:07.613818 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x3c76 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560512791 ecr 0,sackOK,eol], length 0
20:58:08.603603 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x388c (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560513793 ecr 0,sackOK,eol], length 0
20:58:09.563590 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.36371 > 192.168.1.50.22211: Flags [S], cksum 0xcd21 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560514795 ecr 0,sackOK,eol], length 0

また、netcat がすべてのインターフェース (0.0.0.0 の部分) をリッスンしていることもわかります。

$ sudo ss -tulpn | grep 22211
tcp   LISTEN 0      1                               0.0.0.0:22211      0.0.0.0:*    users:(("nc",pid=3344,fd=3))

ルーティング テーブルは次のようになります。

$ sudo route -vn
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 enp1s0
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 enp1s0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp1s0
192.168.1.1     0.0.0.0         255.255.255.255 UH    100    0        0 enp1s0

外部ネットワークから来るパケットがポート 22211 のローカル ソケットに到達しないのはなぜかわかりません... 設定する必要がある追加のファイアウォール設定があるのでしょうか?

編集: 興味深いことに、実際にping 8.8.8.8タイムアウトします (たとえば、google.com への ping は正常に機能します)

答え1

要約

複雑なものが機能しない場合は、まず基本が正しく機能していることを確認してください。

長いバージョン

前文

これは質問の仕方の良い例です。

  1. 背景情報があります。たとえば、Ubuntu 22.04 が実行されており、マシンには 2 つのイーサネット インターフェイスがあります。

  2. 詳細な情報、例えば IP 構成情報などが提供されます。

  3. 動作する例と動作しない例の両方が表示されます。

問題をデバッグしています。

誤解を正します。

  • OP は、「外部ネットワークから来るパケットがポート 22211 のローカル ソケットに到達しないのはなぜかわかりません」と述べています。データではパケットが到着していることが示されていましたが、そのインターフェイスから送信されなかったのは応答でした。

  • OP は、インターフェースが 2 つあると述べました。IP 情報によると、2 番目のインターフェースがダウンしていますが、マシンは他のインターフェースから応答を送信することを期待していたのでしょうか?

詳細情報の最初のリクエスト。

  • 「ルーティングテーブルには、126.33.189.168へのルートがアップしているインターフェース（enp1s0）経由であることが示されていますか？」OPはルーティングテーブルに追加して応答し、次のようにも言いました。

  • 「元のメッセージにルーティング テーブル情報を追加しました。また、他のインターフェイス eno1 がダウンしていることを確認しましたが、変化はないようです」

詳細情報の2回目のリクエスト。

ルーティングテーブルには、数値アドレスではなく、シンボル名が含まれていました。マッピングを知らないと、あまり役に立ちませんでした。

  • sudo route -vn「出力を数値で表示するように編集を変更していただけますか？」

回答者にとって自然な方法で質問してください。

コメントで、ip routeの代わりにを使用することが提案されましたroute -vn。私は長年使用しておりip route、これがより優れたツールであると断言します。問うべき質問は、「私たちは OP に優れたツールを教えようとしているのか、それとも問題の解決を手助けしようとしているのか?」です。新しいツールを導入し始めると、気が散ることになると思います。

詳細情報の 2 回目のリクエスト - 続き。

  • 「192.168.1.50からよく知られているアドレス、例えば8.8.8.8にpingできるかどうかも確認できますか？」これは次のような返答を引き出しました。

  • 「おっしゃる通り、何らかの理由で 8.8.8.8 への ping は失敗します。ただし、google.com への ping は正常に機能します。」

デバッグがping google.com機能する理由

  • 「ping google.com はどの IP アドレスを選択しますか? (最初の行に表示されます。) これは、ファイアウォールで IPv4 を遮断しているものの、IPv6 が完全に機能していることを示しています。」

私はその用語は使いませんfirewalled。ルーティング テーブルに異なるメトリックを持つ 2 つのデフォルト ルートが表示されているため、これはルーティングの問題であることがほぼ確実です。

詳細情報の3回目のリクエスト。

ほとんどの人はインターネットへの接続を 1 つしか持っていませんが、不当な憶測はしないようにしてください。

  • 「それぞれインターネットにアクセスできるルーターが 2 台必要になる予定ですか (おそらく 2 つの異なる ISP を使用)?」

答えが否定的だった場合、OP にルーティングの問題を修正するように伝えるだけで済み (OP が使い慣れたコマンドを使用)、すべてが機能するようになりました。答えを予測し、質問に指示を添えることで、遅延を回避できます。

  • 「8.8.8.8 に ping できることが最も重要な問題です。これを解決すればすべてが解決するかもしれません。」

実際の問題。

  • パケットをローカル ネットワークではなくインターネットに送信する必要がある場合、存在しないマシンを経由するように指示されました。

  • この存在しないマシンにパケットを送信するために、ホストは ARP パケットを送信していましたが、応答がありませんでした。

  • 最終的に、ホストは存在しないマシンへの接続を諦め、ping コマンドにエラーを報告したり、着信接続に対する確認応答を送信しませんでした。

  • ルーティング テーブルを修正して、インターネット宛のパケットを正しいアドレス経由で送信するようにすると、すべてが機能するようになりました。

関連情報