web-dev-qa-db-ja.com

WireGuardを使用したルーティング。実用的な解決策がありますが、ハックのように感じます

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

基本的に、同じネットワークまたは私のLANに戻るトラフィックを除いて、10.30.0.0（ドッカーブリッジネットワーク）からのすべてのトラフィックが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または192.168.0.0および（iptables -s 10.30.0.0/16！-d 192.168.0.0/16など）宛てではない10.30.0.0からのすべてのパケットにマークを付けて、使用する必要がないようにすることを考えました。そのルートですが、私は私の人生のためにそれを理解することはできません。

助けに感謝します

routingiptableswireguard
1
BrodyBuster

テーブル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
1
BrodyBuster