☰

Linux tun インターフェイスパケットルーティング [閉じる]

tag-icon • tag-icon networking routing
Linux tun インターフェイスパケットルーティング [閉じる]

次のシナリオのIPパケットフローについて質問があります。

シナリオは次のとおりです。

  1. クライアントには、tun0（10.0.0.2/8）インターフェイスと物理ワイヤレスネットワークカードwlan0（IPアドレスが固定されていない）があり、インターネットに接続できます。
  2. サーバー側（Ubuntu 12.04 amd64）には、別のtun0（10.0.0.1/8）インターフェイスと物理イーサネットカードeth0（192.168.1.38/24）があり、eth0はNATファイアウォールの背後にあるプライベートネットワークにあり、ファイアウォールを介したインターネット（ゲートウェイ）としてのファイアウォール）、
  3. echo 1 > /proc/sys/net/ipv4/ip_forwardサーバー側で ""を実行します。
  4. iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADEサーバー側で ""を実行します。

シーングラフは次のとおりです。

---------------          ----------------
|             |          |              |
| client tun0 |----------| client wlan0 |
|  10.0.0.2   |          |  ip not fix  |
|             |          |              |
---------------          ----------------
                                |
                                |

                             internet

                                |
                                |
                         ----------------
                         |              |
                         |   firewall   |
                         |   (gateway)  |
                         | 192.168.1.1  |
                         |              |
                         ----------------
                                |
                                | private network
                                | 192.168.1.0/24
                                |
---------------          ----------------
|             |          |              |
| server tun0 |----------| server eth0  |
|  10.0.0.2   |          | 192.168.1.38 |
|             |          |              |
---------------          ----------------

私は2つの非常に単純なVPNに似たクライアント/サーバープログラムを使用して2つのtun0インターフェイスのIPパケットを読み書きし、10.0.0.2から来るIPデータに対してwlan0とeth0の間にトンネルを作成しました。パケットは10.0.0.1に達することができ、その逆も同様です（例えば、10.0.0.1から10.0.0.2までftpを実行できます）。

ただし、クライアントtun0（10.0.0.2）を使用してWebを閲覧する場合は、http要求は10.0.0.2で行われ、インターネットIPアドレス（確かに10.0.0.1ではありません）に到達します。 httpリクエスト（私の意見では）がサーバーtun0（10.0.0.1）に達した後、サーバーeth0に転送されます（ip_forwardがオンになっているため、転送されたこのhttpリクエストはまだソースIPアドレス10.0.0.2を持つと思います） . 間違っています。 修正してください。 次に、NAT を実行して eth0 の http 要求を再パッケージ化します。を通過し（その後、インターネット）が目的地に到達します。

ウェブサイトのhttp応答がサーバーeth0に到達したら、そこでリバースNATを実行する必要があります。私の質問は次のとおりです

  1. リバースNATはhttp応答の宛先IPアドレスを10.0.0.2に復元します。
  2. サーバーeth0は、リバースNATのhttp応答をどこに渡すのかをどのように知ることができますか？
  3. 応答の宛先IPアドレスが10.0.0.2にリバースNAT化されているため、eth0はhttp応答をサーバーtun0（10.0.0.1）に転送しますか？
  4. リバースNATへのhttp応答を正しくルーティング/配信するには、サーバー側にパスを追加する必要がありますか？それではどうですか？
  5. リバースNATへのhttp応答を正しくルーティング/配信するには、サーバー側にいくつかのiptablesルールを追加する必要がありますか？それではどうですか？

答え1

クライアントが tun0 を介してすべてのトラフィックを送信すると仮定すると、サーバー側で次のものを追加する必要があります (/proc/sys/net/ipv4/ip_forward を有効にした後)。

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

この手順を完了した後、クライアントがWebを閲覧したときのパケットフローは次のとおりです。

  1. クライアントはパケットを 10.0.0.1 に送信します。
  2. サーバー側では、tun0で受信されたパケットは10.0.0.2から192.168.1.38に変換されます。
  3. NATテーブルにマッピングエントリが作成されます。
  4. パケットは192.168.1.1（ゲートウェイ）を介してインターネットに送信されます。
  5. 応答は192.168.1.38として受信されます。
  6. ステップ3で作成されたマッピング項目に基づいてリバースNATが実行されます。
  7. 応答パケットは 10.0.0.2 に再ルーティングされます。

いくつかの重要なステップを見逃していないことを願っています。 :)

関連情報