☰

内部ネットワークから静的 IP に ping できません。外部からのみ可能です。

tag-icon • tag-icon networking ping localhost
内部ネットワークから静的 IP に ping できません。外部からのみ可能です。

私はUbuntuを使っていて、Apacheも実行していますが、静的IPに内部的にpingすることも、http://207.40.XXX.XX静的IPを使用してWebサーバーを閲覧することもできません。ping/閲覧のみ可能です。localhost, 127.0.0.1, and 192.168.0.120 または 207.40.XXX.XX外の世界からのみ。

# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       my-server.myhost.com my-server

# hostname
my-server

# netstat -tapn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:29754         0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN

なぜこれが機能しないのか、何か考えはありますか?

答え1

NAT ゲートウェイは、これを許可するような動作をしていません。おそらく、次のように動作します。

ピン

  1. 192.168.0.5から207.40.123.45にICMPエコー要求を送信します。
  2. これはルーターを経由してルーティングされます。
  3. ルーター内のNATゲートウェイは、リクエストを207.40.123.45（静的IPアドレス）からのものになるように書き換えます。
  4. ルータはICMPエコー要求に応答します
  5. ルータは ICMP 状態をサポートしていないため、ECHO 応答を返すことはありません。

ウェブ

  1. 192.168.0.5から207.40.123.45にTCP/80接続要求を送信します。
  2. これはルーターを経由してルーティングされます
  3. NATゲートウェイはパケットを次のように書き換えます。から207.40.123.45:41345 から 207.40.123.45:80
  4. NATゲートウェイはポート転送が設定されていることを認識し、パケットを192.168.0.120:80に転送します。
  5. 192.168.0.120のサーバーは、207.40.123.45:41345からの接続試行に応答します。
  6. NAT ゲートウェイは応答を確認し、応答の To: アドレスを 192.168.0.5:36311 に書き換えますが、From: は変更しません (192.168.0.120:80)。
  7. 192.168.0.5 のコンピュータは、要求したことのない 192.168.0.120 からのパケットを受信し、それを破棄します。
  8. 接続が遅くなり、開かなくなります。

注意: ping が失敗する理由は、HTTP が失敗するのと同じ理由である可能性があります。これは「NAT ヘアピニング」と呼ばれます。

必要なのは、ステップ6で次の内容を書き換えるほど賢いNATゲートウェイです。ソース住所。

答え2

1138 さんの回答は正しいのですが、私は「ヘアピン NAT」とは何か、どのように機能するのか、そしてなぜこの状況で必要なのかを詳しく説明したいと思いました。IP、NAT、ルーティングの細かい詳細に興味がない場合は、私の回答の残りの部分 (かなり長い) は無視してください。

ヘアピンがない場合、ローカル LAN クライアント (192.168.0.5) から外部 IP アドレス (207.40.123.45) 経由で Web サーバーに HTTP 接続を試行すると、次のことが起こります。

  1. 192.168.0.5 は SYN パケットを 207.40.123.45 のポート 80 に送信します。207.40.123.45 はローカル ネットワーク上にないため、このパケットはデフォルト ゲートウェイ (つまり、ルーター) に送信されます。

  2. 207.40.123.45:80 を 192.168.0.120:80 に転送するように設定されているルータは、パケットの宛先アドレスを 192.168.0.120 に書き換えてから、パケットを Web サーバーに配信します。

  3. ウェブサーバーはSYNパケットを受信し、送信者のアドレスに返信SYN-ACKパケットを送り返します。192.168.0.5192.168.0.5 は同じネットワーク上にあるため、Web サーバーはパケットを 192.168.0.5 に直接配信します。

  4. SYN-ACKパケットは192.168.0.120192.168.0.5 に到着しますが、そこのホストは 192.168.0.120 からの SYN-ACK を期待していなかったため、ドロップ/拒否されます。192.168.0.5 のホストは 207.40.123.45 からの応答 SYN-ACK を待ち続けますが、もちろんそのパケットが到着することはありません。接続試行はおそらく数回の再試行の後にタイムアウトし、最終的にクライアントと Web サーバーは接続を確立できなくなります。

この問題は、ステップ 2 でルーターが「ヘアピン NAT」を適用することで解決できます。簡単に言うと、解決策はクライアントと Web サーバーを騙して相互のトラフィックをルーター経由で送信することです。これは、次の方法で巧みに実現されます。NATの第2フェーズステップ 2 では、ポート転送に通常適用される 1 つのフェーズに加えて、ヘアピニング NAT が追加されたシーケンスが再度示されます。

  1. 前と同様に、192.168.0.5 は、207.40.123.45、ポート 80 宛ての SYN パケットをルーターに送信します。

  2. 前回と同様に、ルータはSYNパケットを受信し、設定されたポート転送ルールに従って、宛先アドレスを192.168.0.120に書き換えます。ただし、今回は、ルータはパケットを受信したのと同じネットワークに「ヘアピン」しようとしていることに気付き、パケットの送信元アドレスルータ自身の LAN アドレス (たとえば、192.168.0.1) に送信します。ルータはパケットを 192.168.0.120 の Web サーバーに配信します。

  3. ウェブサーバーはSYNパケットを受信し、その返信SYN-ACKパケットを送信者のアドレスに返します。今回は、192.168.0.1したがって、応答はルータに戻ります。

  4. ルーターはウェブサーバーから SYN-ACK を受信し、それが最近 NAT された (2 回) パケットへの応答であることを認識します。そのため、ルーターは忠実に両方の NAT を反転し、応答パケットの送信元アドレスは 207.40.123.45、宛先アドレスは 192.168.0.5 になります。したがって、応答は 192.168.0.5 に配信され、TCP 接続ハンドシェイクが続行され、クライアントとウェブサーバーは正常に通信できるようになります。

したがって、ルーターでヘアピン機能がサポートされている場合、192.168.0.5 のホストは 207.40.123.45 の Web サーバーと通信していると考え、192.168.0.120 の Web サーバーはルーター自体 (192.168.0.1) のクライアントと通信していると考えます。ヘアピン機能を使用すると、2 つのホストが実際には同じネットワーク上にあるにもかかわらず、2 つのホスト間のすべてのトラフィックがルーターを通過します。これは明らかにネットワーク リソースの最適ではない使用法であり、ヘアピン機能に頼るよりも分割 DNS を設定する方が望ましい主な理由です。

答え3

どのようなファイアウォールを使用していますか? NAT ヘアピンが有効になっていないようです。

関連情報