☰

本当に奇妙な Debian の問題: パブリック IP からは Debian で実行されているどのサービスにも接続できませんが、プライベート IP では問題なく動作します

tag-icon • tag-icon networking debian
本当に奇妙な Debian の問題: パブリック IP からは Debian で実行されているどのサービスにも接続できませんが、プライベート IP では問題なく動作します

まず、これはポート転送の問題ではありません。tcpdump を実行すると、リクエストが Debian サーバーに到達し、その後停止することがわかります。

私の Debian サーバーは、Apache と PleX を実行しています。192.168.1.210 を使用して Debian サーバーに接続すると、問題なく動作します。Web ページを表示でき、PleX からストリーミングできます。

たとえば、自分のネットワークを離れて友達の家に行くと、どちらにもアクセスできなくなります。tcpdump を使用すると、パケットがサーバーに到達したことを確認できますが、それだけです。canyouseeme.org でも同様です。

私するルーティングと iptables をいくつか用意します。このマシンはトレントと VPN に使用しているため、ルーティングを使用してすべてが機能するようにしています。ルーティングは PleX を tun0 (VPN インターフェイス) から遠ざけることを目的としており、iptables はユーザー debian-transmission が tun0 以外を使用しないようにすることを目的としているはずです。

 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.172.1.5      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.172.1.1      10.172.1.5      255.255.255.255 UGH   0      0        0 tun0
10.172.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
50.18.0.0       192.168.1.1     255.255.0.0     UG    0      0        0 eth0
54.241.0.0      192.168.1.1     255.255.0.0     UG    0      0        0 eth0
128.0.0.0       10.172.1.5      128.0.0.0       UG    0      0        0 tun0
184.72.0.0      192.168.1.1     255.255.192.0   UG    0      0        0 eth0
184.169.128.0   192.168.1.1     255.255.128.0   UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
216.144.236.186 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0

iptables:

target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.1.0/24       owner UID match debian-transmission
REJECT     all  --  anywhere             anywhere             owner UID match debian-transmission reject-with icmp-port-unreachable

答え1

おそらく、何が起こっているのかを例で説明するのが最も簡単です。

NAT ルーターの IP アドレスが 1.1.1.1 で、友達の IP アドレスが 2.2.2.2 だとします。また、説明を簡単にするために、友達が NAT ルーターの背後にいないと仮定します (NAT ルーターの背後にいた場合、例が少し複雑になりますが、問題は根本的に変わりません)。また、ポート転送によって、外部 IP のポート 80 が Debian ボックスのポート 80 に転送されると仮定します。

友人のコンピュータは、送信元アドレス2.2.2.2、ランダムに選択された送信元ポート（12345とします）、宛先アドレス1.1.1.1、宛先ポート80のSYNパケットを送信します。

パケットが NAT に到達すると、NAT はポート転送を検索し、宛先 IP を 192.168.1.210 に変更します。送信元 IP は 2.2.2.2 のままで、ポートは同じままです。マッピングが作成され、返されるパケットに対して逆変換を実行できるようになります。ここまでは順調です。

パケットがサーバーに到達します。TCP スタックに配信され、応答として ack パケットが作成されます。通常、パケットが返信されると、送信元と宛先が入れ替わります。したがって、パケットの送信元アドレスは 192.168.1.210、宛先アドレスは 2.2.2.2、送信元ポートは 80、宛先ポートは 12345 になります。

応答は TCP スタックを離れ、iptables に到達します。ルールは UID の一致を実行しているため、所有者の一致は正しく機能し、パケットはそこを通過するはずです。

次に、ルーティング テーブルに到達します。これにより、VPN に送信されます。VPN 内の NAT に到達し、何らかの方法でソースが変更され、友人に戻りますが、ソース アドレスが間違っているためドロップされます。

考えられる修正方法: 1: ルーティング テーブルに友達の IP アドレスを追加します。これは明らかにあまり拡張性がなく、トレント トラフィックの漏洩を引き起こす可能性があります。 2: NAT ボックスが適切な Linux システムである場合は、受信接続の送信元と送信先を変更するように構成できるはずです。そうすると、トレント ボックスはインターネット上の友達のシステムではなく、NAT ボックスを送信元として認識します。 3: Linux の「高度なルーティング」機能を使用して、送信元ポートに基づいてルーティングします。残念ながら、高度なルーティング機能は非常に強力ですが、理解しにくいです。このルートを実行する方法の詳細については、「Linux の高度なルーティングとトラフィック制御のハウツー」を参照してください。

関連情報