WireGuard を使用したルーティング。実用的なソリューションではあるが、ハックのような感じ

WireGuard を使用したルーティング。実用的なソリューションではあるが、ハックのような感じ

Docker ネットワークからのトラフィックをルーティングしようとしています... Wireguard が稼働しており、宛先に基づいてすべてのトラフィックを VPN 経由でルーティングするドキュメントの例とは異なり、ソース ネットワーク、ポリシー ルーティング、宛先に基づいてトラフィックの一部のみをルーティングしようとしています。

基本的に、同じネットワークまたは自分の LAN に戻るトラフィックを除き、10.30.0.0 (docker ブリッジ ネットワーク) からのすべてのトラフィックが wg0 インターフェイスを通過するようにしたいです。つまり、基本的には発信インターネット トラフィックだけです。

静的ルートを使用して、ある程度動作させています。

post-up ip rule add from 10.30.0.0/16 table 200
post-up ip route add default via a.b.c.d metric 2 table 200
post-up ip route add blackhole default metric 3 table 200
post-up ip route add 192.168.0.0/16 via 192.168.0.1 table 200
post-up ip route add 10.30.0.0/16 via 10.30.0.1 table 200

10.30.0.0 からのすべてのトラフィックにテーブル 200 を使用し、デフォルト ルートは wg0 を経由します。フォールバック ルートは、wg0 がダウンした場合のブラックホール キル スイッチです。

次の 2 つのルートは、wg0 の周りの内部のルーティングを処理します。そうしないと、コンテナーはネットワーク上で互いに通信できず、WebGUI にアクセスできません。これは完璧に機能します。

ただし、/etc/network/interfaces.d/wg0 でこれらのルートを呼び出すと、適切なルートを使用してインターフェイスが作成され、起動されます。このルート以外はすべて正常です。

post-up ip route add 10.30.0.0/16 via 10.30.0.1 table 200

wg0 が起動したときに docker ブリッジがまだ起動していないため、ゲートウェイがないためルートを作成できず、失敗します。とりあえず、これをハックして、cron で "@reboot" を使用して、docker ネットワークが起動した後にこのルートを起動するようにしました。

もっとエレガントな解決策はありますか? 10.30.0.0 から送信され、10.30.0.0 または 192.168.0.0 宛ではないすべてのパケットをマークし、(iptables -s 10.30.0.0/16 ! -d 192.168.0.0/16 など)、そのルートを使用する必要がないようにすることを考えましたが、どうしてもわかりません。

ご協力いただければ幸いです

答え1

私は、それらのローカルルートのルートをテーブル200に持つ代わりに、メインテーブルを呼び出すことでそれを解決しました。

post-up ip rule add from 10.30.0.0/16 table 200
post-up ip rule add from 10.30.0.0/16 to 192.168.0.0/16 table main
post-up ip rule add from 10.30.0.0/16 to 10.30.0.0/16 table main
post-up ip route add default via a.b.c.d metric 2 table 200
post-up ip route add blackhole default metric 3 table 200

関連情報