☰

同じネットワークとインターフェース上のゲートウェイを持つルーティング テーブル、なぜですか?

tag-icon • tag-icon linux networking routing
同じネットワークとインターフェース上のゲートウェイを持つルーティング テーブル、なぜですか?

弊社の VPN に接続してルーティング テーブルを確認すると、次のことがわかります。

172.16.0.0      10.8.0.241      255.255.0.0     UG    0      0        0 tun0
10.8.0.241      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.241      255.255.255.0   UG    0      0        0 tun0

最初の行は次のように理解していると思います: 172.16 ネットワークへのパケットは tun0 インターフェイスにドロップされますが、残りの処理はゲートウェイ 10.8.0.241 にアドレス指定されて処理されます。

2 行目では、10.8.0.241 にアクセスするには、tun0 にドロップするだけでよいことが明示的に示されています。

私が理解できないのは、最後の2行をなぜ結合できないのかということです。

10.8.0.0        0.0.0.0      255.255.255.0   UG    0      0        0 tun0

10.8 宛てのパケットは、トンネルにドロップするだけで、適切なマシンがそれを受け取ることができると言いたいのですが、10.8 宛てのパケットは、なぜ最初に同じネットワークのゲートウェイに明示的に渡されなければならないのでしょうか。10.8.0.251 は、実際には tun0 のもう一方の端に直接接続され、10.8 宛てのパケットを転送する方法を知っている唯一のマシンであるため、ここではスイッチとして誤用されているのでしょうか。

答え1

この質問に答える前に、リンクされているフラグについて説明させてください。

  • U (ルートはアップ)
  • H (ターゲットはホスト)
  • G (ゲートウェイを使用)

ルート2と を3組み合わせることはできません。これは、ソース マシンに10.8.0.241直接 ( metric 0) 到達するように通知し、ネットワーク ID を持つマシンに到達するには10.8.0.0/24ゲートウェイ を使用するように10.8.0.241通知しているためです。パケットをデフォルト ゲートウェイに転送する理由がわかりませんが、これがゲートウェイ ルーター/ファイアウォールに逆ルートを挿入するためのトリックである可能性があります。

答え2

推測すると、ネットワークのトポロジは次のようになります。

クライアント => インターネット => 10.8.0.241 => 10.8.0.0/24

VPN が確立されると、tun0 経由で VPN エンドポイント以外のホストに直接接続することはできません。10.8.0.0/24 の範囲内の他のものにデータを送信するには、データを GW (10.8.0.241) に送信する必要があります。その後、GW はデータを正しいホストに転送します。

これにより、リモート エンドポイントのサーバーと同じネットワーク上の IP が提供され、他の VPN クライアントに接続できるようになります。

関連情報