iptablesがconnmarkを設定しているが、IPルールが一致しない


0

Ubuntu 17.10 VMをセットアップして、複数のVPN接続を使用し、それらの間の接続の負荷を分散しようとしています。複数のopenvpnクライアントを実行し、iptables / connmarkで接続をマークし、モードランダムを使用して異なる接続を異なる値でマークしてから、これらを異なるVPNルーティングテーブルと一致させて、これを実行しようとしています。しかし、私は成功していないので、状況を単純化して、何が間違っているのかを理解しようとしました。

シナリオを単一のVPN接続に減らし、すべてのルーティングロジックを専用のルーティングテーブルに入れ、すべてのパケットにそのルーティングテーブルを使用するようにマークしようとしました。

すべてのトラフィックがそのテーブルを使用するように強制すると、正常に機能します。すべてのパケットをマークし、そのマークを一致させてテーブルを使用しようとすると、機能しません。

有効なルールは次のとおりです。

0:すべてのローカル検索から
10:すべてのルックアップVPN2から
32766:すべてのルックアップメインから
32767:すべての検索デフォルトから

動作しないルールは次のとおりです。

0:すべてのローカル検索から
10:すべてのfwmark 0x14ルックアップVPN2から
32766:すべてのルックアップメインから
32767:すべての検索デフォルトから

そして、ここにすべてをマークするはずのiptablesマングルテーブルがあります。

#iptables -nvL -t mangle
チェーンPREROUTING(ポリシーACCEPT 6785パケット、464Kバイト)
 pktsバイトターゲットprot opt in outソースdestination
 8013 545K CONNMARK all-* * 0.0.0.0/0 0.0.0.0/0 CONNMARK復元
 7981 543K MARK all-* * 0.0.0.0/0 0.0.0.0/0 MARK set 0x14
 7958 541K CONNMARK all-* * 0.0.0.0/0 0.0.0.0/0 CONNMARK保存

チェーンINPUT(ポリシーACCEPT 6773パケット、463Kバイト)
 pktsバイトターゲットprot opt in outソースdestination

チェーンフォワード(ポリシーACCEPT 0パケット、0バイト)
 pktsバイトターゲットprot opt in outソースdestination

チェーン出力(ポリシーACCEPT 4382パケット、1132Kバイト)
 pktsバイトターゲットprot opt in outソースdestination
 4636 1159K CONNMARK all-* * 0.0.0.0/0 0.0.0.0/0 CONNMARK復元
 4516 1146K MARK all-* * 0.0.0.0/0 0.0.0.0/0 MARK set 0x14
 4382 1132K CONNMARK all-* * 0.0.0.0/0 0.0.0.0/0 CONNMARK保存

チェーンPOSTROUTING(ポリシーACCEPT 4151パケット、1116Kバイト)
 pktsバイトターゲットprot opt in outソースdestination

ここで自分のルールが少し無意味であることを理解しています(復元、とにかくマークする前)が、問題がどこにあるかを理解するためにすべてをマークするようにしようとしています。

私が言うように、すべてがVPN2ルーティングテーブルを使用している場合、それはうまく動作します-そして、私は200x14)でマークされた接続を見ることができますconntrack -L

しかし、マークに基づいてルーティングを行おうとすると、それは機能せずconntrack -L、でSYN_SENTステータスが表示されていても、接続試行は表示されませんnetstat。また、ソースIPは私のVPN tunインターフェースではないため、テーブルは使用されていません。

これをデバッグするためのアドバイスは大歓迎です。

どうもありがとう


私が理解していることから:出力でマングルが使用されると、ルート変更チェックがトリガーされます。これは、fwmarkルールを使用するこの2回目のルーティングチェックです。ただし、IPは最初のルーティングチェックですでに選択されています。あなたもナットをやってみてください。とにかく、出力が期待どおりに動作しない場合は、出力をテストする前に(他のvmまたはネットワーク名前空間からの)事前ルーティングのテストに集中する必要があります。Netfilterのと一般的なネットワークでのパケットフロー
AB

私はまだ完全に理解していませんが、あなたが言及した「再ルーティング」で私を正しい軌道に乗せたと思います。私はこの記事を見つけた、と私は再ルーティングが起こる前に、私のフィルタテーブルがパケットをフィルタリングしていると思う: linuxquestions.org/questions/linux-networking-3/...
ダニーTrigo

とても感謝しています。すべてのフィルターを一時的に削除し(どのようにそれらを再追加するかわからない)、NAT /出力チェーンにSNATルールを追加し、フィルタリングを防ぐためにこれを2に設定することにより、接続を異なるインターフェイスにランダムに送信することに成功しました返されるパケット:/ proc / sys / net / ipv4 / conf / tun1 / rp_filter。おかげで再び
ダニーTrigo
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.