web-dev-qa-db-ja.com

tun1を介したtun0トラフィックのルーティング（ダブルホップVPN）

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

$ ip route show：

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
linuxvpnroutingtunneling
1
qatime
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つの方法で対処できます。

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

複数のルーティングテーブルが存在する可能性があり、ルール/ポリシーに基づいて、デフォルト以外のトラフィックによって処理されるトラフィックを管理できます。このようにして、デフォルトのGWがtun1であり、tun0からのトラフィックのみがこのカスタムルーティングテーブルを指すようにカスタムルーティングテーブルを設定できます。

  • ネットワーク名前空間

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

0
Kamil J

目的のシーケンスが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のエンドポイントがあることがわかります。 tun0を経由するこのIPアドレスには特定のルートがあります

 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を通過する必要がありますしたがって、データは両方のトンネルを通過します。

パケットがトンネルを介してトンネリングされていることを認識していないため、tracerouteはこれを表示しません。それでも、下位レベルを確認することで、これが発生していることを確認できます。別のウィンドウで「Sudo tcpdump -n-iany」を実行しながらトラフィックを生成します。パケットがより広いインターネットに送信されるときはいつでも、パケットはeth0、tun0、tun1のそれぞれを介して送信され、返されたパケットにも同じことが当てはまることがわかります。 tun0に関連付けられたパケットはすべて、101.133.213.73のターゲットを持ちます。

0
davidgo