☰

tun0 トラフィックを tun1 経由でルーティングする (ダブルホップ VPN)

tag-icon • tag-icon linux vpn routing tunneling
tun0 トラフィックを tun1 経由でルーティングする (ダブルホップ VPN)

目標: ダブルホップ VPN のために、すべてのインターネット トラフィックを eth0 -> tun0 -> tun1 にルーティングします。次のルーティング テーブルはその目標に対して正しいでしょうか?

$ ip ルート ショー:

0.0.0.0/1 via 10.8.1.1 dev tun1 
default via 10.8.3.1 dev tun0 proto static metric 50 
10.8.1.0/24 dev tun1 proto kernel scope link src 10.8.1.6 
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.4 metric 50 
101.133.213.73 via 10.8.3.1 dev tun0 
127.0.0.0/8 dev lo scope link 
128.0.0.0/1 via 10.8.1.1 dev tun1 
191.72.65.45 via 182.160.0.1 dev eth0 proto static metric 100 
182.160.0.0/24 dev eth0 proto kernel scope link src 182.160.0.19 metric 100 
182.160.0.0/24 dev eth0 proto dhcp scope link src 182.160.0.19 metric 208 
182.160.0.1 dev eth0 proto static scope link metric 100

答え1

eth0 : 182.160.0.19/24 (GW: 182.160.0.1)
tun0 : 10.8.3.4/24 (GW: 10.8.3.1 / VPN endpoint : 191.72.65.45 via eth0)
tun1 : 10.8.1.6/24 (GW: 10.8.1.1 / VPN endpoint : 101.133.213.73 via tun0)

この方法では、イーサネット (182.160.0.0/24) 上のローカル トラフィックと tun0 / "VPN1" (10.8.3.0/24) 上のローカル トラフィックを除くすべてのトラフィック (tun0 からの着信を含む) が tun1 経由でルーティングされます。

このルーティングテーブルではまた、eth0からのすべてのトラフィックはtun1経由でルーティングされます。質問では言及/要求されていません... この状況は問題ありませんか? 答えが「はい」の場合は、この設定を維持できます。

これが望ましくない状況である場合（eth0 から tun1 / tun0 にトラフィックをルーティングしたくない場合）、対処方法としては（少なくとも） 2 つのオプションがあります。

  • 「カスタム」ルーティングテーブル

ルーティング テーブルは 1 つだけではなく、ルール/ポリシーに基づいて、デフォルト以外のルーティング テーブルで処理されるトラフィックを管理できます。この方法では、デフォルトの GW が tun1 になるカスタム ルーティング テーブルを設定し、tun0 からのトラフィックのみがこのカスタム ルーティング テーブルにポイントされるようにすることができます。

  • ネットワーク名前空間

この方法では、tun インターフェイス全体を eth0 から分離できるため (名前空間間の内部ルーティングを使用)、名前空間内に単純な (デフォルトの) ルーティング テーブルを設定して、tun0 からのトラフィックのみが tun1 に到達できるようになります。

答え2

望ましいシーケンスが LAN からのトラフィックがローカル マシン -> tun0 -> tun1 に送信されることであると仮定すると、これが実際に起こっている可能性がありますが、tracreroute では表示されない方法で発生しています。

任意のインターネット アドレス宛てのパケットを考えてみましょう。この例では 8.8.8.8 を使用します。

コンピュータはパケットを拾い、送信方法を探します。tun1 経由で送信する必要があることがわかります (以下の 2 つのルートはデフォルト ルートと同等ですが、より制限されているため、デフォルト ルートよりも優先されます。この場合は最初のルートがヒットします)。

 0.0.0.0/1 via 10.8.1.1 dev tun1
 128.0.0.0/1 via 10.8.1.1 dev tun1

しかし、ここは明らかではない部分です。tun1の設定を見ると、エンドポイントが101.133.213.73であることがわかります。このIPアドレスにはtun0を経由する特定のルートがあります。

 101.133.213.73 via 10.8.3.1 dev tun0

同様に別のルートもある

  191.72.65.45  via 182.160.0.1 dev eth0 proto static metric 100

このルートにより、tun0 経由で送信されたトラフィックがイーサネット インターフェイスを介して直接アクセス可能になります。

これは非常に特殊なルートであるため、101.133.213.73へのトラフィックはtun0を経由します。したがって、インターネットに流れるすべてのトラフィック（tun1経由）は、それ自体がトンネルである101.133.213.73を経由する必要があります。つまり、データは両方のトンネルを通過します。

パケットはトンネルを経由していることを知らないため、トレースルートではこのことは表示されません。とはいえ、下位レベル (別のウィンドウで「sudo tcpdump -n -i any」を実行しながらトラフィックを生成する) を調べることで、これが起こっていることを確認できます。パケットがインターネット全体に送信されるたびに、eth0、tun0、tun1 のそれぞれを介してパケットが送信され、返されるパケットについても同じことが当てはまることがわかります。tun0 に関連付けられたパケットはすべて、ターゲットが 101.133.213.73 になります。

関連情報