☰

カスタムルートテーブル内のVPNゲートウェイが失敗する

tag-icon • tag-icon iptables vpn routing linux-networking iproute2
カスタムルートテーブル内のVPNゲートウェイが失敗する

私の目標は、複数の VPN 接続にわたって負荷分散するルーターとして動作するコンテナを構成することです。

これを実現するために、私は開始パケットを次のように確率的にマークしています。

iptables -I PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A PREROUTING -t mangle -m statistic --mode random --probability .50 -j MARK --set-mark 200 -m mark --mark 0
iptables -A PREROUTING -t mangle -j MARK --set-mark 201 -m mark --mark 0
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

次の 2 つのルーティング テーブルのいずれかを選択します。

echo "200     tun0" >> /etc/iproute2/rt_tables
echo "201     tun1" >> /etc/iproute2/rt_tables 
ip rule add fwmark 200 table tun0
ip rule add fwmark 201 table tun1

ルーティング テーブルは正しく選択されていると思います。なぜなら、いずれかのテーブル tun0/1 を VPN ゲートウェイを使用するように構成すると、トラフィックが返されないように見えるからです。A はtcpdumpトラフィックの終了を示していますが、どのコマンドも失敗します。

ip route add default 10.7.7.1 dev tun0 table tun0
ip route add default 10.7.7.1 dev tun1 table tun1

テーブル tun0/1 が非 VPN ゲートウェイ10.10.10.1トラフィックを使用する場合、期待どおりに動作します。メイン テーブルでデフォルト ルートを設定することで、VPN ゲートウェイを選択することもできます。

ip route add default 10.7.7.1 dev tun0/1

したがって、問題は、VPN ゲートウェイがメイン テーブルではなくカスタム テーブルの 1 つを介して選択されたときに発生するようです。ヒント、診断、アドバイスがあれば歓迎します。

注: 必要なオプションを設定しました:

echo 0 > /proc/sys/net/ipv4/conf/**/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
sysctl -w net.ipv4.fwmark_reflect=1
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

答え：

@AB の回答が解決策を示しています。tun0/1 テーブルに、ローカル ネットワークに戻るトラフィックのルートを追加する必要があります。

ip r a 10.10.10.0/24 via 10.10.10.1 table tun0
ip r a 10.10.10.0/24 via 10.10.10.1 table tun1

@AB が言ったように、これらのマークがないと、パケットは受信されたトンネルから送り返されます。

答え1

何が起こるか見てみましょう。

  • パケット（新しいフローの最初のパケット）が非トンネルインターフェースから到着する
  • 接続トラックこのパケットに新しいエントリを作成し、新しいフローを開始します
  • パケットはルーティング決定前に（ランダムに、今回は）マーク200を受信する
  • パケットはテーブル200を使用してルーティングされる
  • 表200には1つの可能性がある。パケットはトゥン0
  • パケットのマークはフロー全体にわたって保存され、接続トラックエントリー（つまり、コネマーク）。

これまでのところ、パケット（およびそのフロー）は、トゥン0。

さて、返事このフローのパケットは戻ってきますか?

  • 応答パケットが到着トゥン0

  • 応答パケットは次のように識別されます接続トラック既存のフローの一部として

  • パケットはマーク200を継承しますコネマークルーティング決定前に既存のフローに関連付けられている

  • パケットはテーブル200を使用してルーティングされる

  • 表200には1つの可能性がある。パケットはトゥン0

    残念: 応答パケットは、フローの最初のパケットの送信元ではなく、送信元であるトンネル インターフェイスからルーティングされます。

  • ネクストホップ ルータ (トンネルのリモート エンドポイント) でも Strict Reverse Path Forwarding ( rp_filter=0) が無効になっているかどうかに応じて、パケットはドロップされるか、または再びルーティングされて、TTL が 0 に達するまでループが作成されます。

したがって、問題は、VPN ゲートウェイがメイン テーブルではなくカスタム テーブルの 1 つを介して選択された場合に発生するようです。

確かに、主要ルーティングテーブルには複数のデフォルトルートがあります。通常、1つ以上のLANルートが含まれます。したがって、マークが関係しない場合は、応答は評価に従って正しくルーティングされます。全てデフォルトのルートに従うだけでなく、メインのルーティング テーブル エントリに従います。

これらの追加のLANルート：eth0そしてeth1または、少なくともクライアント要求に関係するもの（両方ではない）も、追加のルーティング テーブル 200 および 201 にコピーする必要があります。

追加のコメント（OP のケースには当てはまりません）: 逆方向に動作する設定では、同じサービスに向けてまったく同じ (プライベート) IP 送信元アドレスを使用する別のノードからの元のフローは、トンネル インターフェイスを除いて同一に見える 2 つの異なるフロー (同じ 5 組のプロトコル、saddr、sport、daddr、dport) になる可能性があります。デフォルトでは接続トラック単一のフローしか見られません。これを防ぐには、conntrackゾーン（インターフェースを表すために選択された値を持つ）接続トラック別々に処理します。

関連情報