nftables, masquerade: パケットが無効なアウトバウンドインターフェイスを通過する

Question

注意と調整（混乱によるものかもしれません）：

WireGuardピアが一致するために10.8.0.107の代わりに10.8.0.105を使用するとします。nftablesルールセット。
233.252.0.0はシミュレーションで問題を引き起こす可能性があります（特に次の場合）。仲間）マルチキャストアドレスだからです。以下では192.0.2.233を使用します（192.0.2.2とネットワーク関係はありません）。

この質問は、ローカルトラフィックだけでなく転送にdnatルールを使用する問題を解決することです。最後に修正されたWireGuardトンネルエンベロープにも隠された問題があります。

pingテスト（事前ルーティングで発生する実際のdnatとレスポンスで発生するマスキング解除を含む）によるルーティングスタックの動作は、カーネルにどのパスを問い合わせるかを問い合わせる次の2つのコマンドにまとめることができます。使用：

# ip route get from 192.0.2.2 iif ens19 to 10.8.0.105
10.8.0.105 from 192.0.2.2 dev wg0 
    cache iif ens19 
# ip route get from 10.8.0.105 iif wg0 to 192.0.2.2
192.0.2.2 from 10.8.0.105 via 203.0.113.1 dev ens18 
    cache iif wg0

ここでは、応答が間違ったインターフェイスを使用していることがわかります。アドレスが書き換えられます。つながるアイテムの内容：上記に表示されていなくても、198.51.100.105です。

これは不足しているルールが原因で発生します。any from（returns）ワークグループ0テーブルを使用する必要がありますサブネット。次に修正されました：

ip rule add iif wg0 lookup subnets

これも問題を解決しました。rp_filter=1RTNETLINK answers: Invalid cross-device link上記の最初のパステストは通常追加する必要がありますが、失敗します。ワークグループ0パスもこの表にあります。

今与えられた：

# ip route get from 10.8.0.105 iif wg0 to 192.0.2.2
192.0.2.2 from 10.8.0.105 via 198.51.100.1 dev ens19 table subnets 
    cache iif wg0

これで、pingテストは正常に動作します。

追加の隠しWireGuardエンベロープルーティングの問題があります。

コンビネーション：

有効ではありません厳格なリバースパス転送（RFC 3704)
ピアが最初にサーバーに接続するようにします（最後の追加の質問を参照）。
（少なくとも）カーネルの実装は、もともと接触していたのと同じソースを使用して応答する必要があると判断します。

WireGuardの動作を許可しますping 10.8.0.1。仲間応答が受信され、その後のWireGuardトラフィックは同じエンベロープアドレスを使用し続けることができます。

ローカル（ルーティングされていない）フローのソースアドレスが宣言されていない場合、ルーティングスタックは指定されたパスにどのアドレスを使用するべきかを把握する必要があります。これは、ソケットが通常バインドされていないままであるUDPの場合に特に重要です（つまり、ソースは0.0.0.0、つまりINADDR_ANYです）。 TCPサーバーの場合、後で作成された冗長ソケットはaccept(2)0.0.0.0にバインドされなくなり、正しいアドレスにバインドされるため、これは問題になりません。次に、このアドレスをルーティングスタックに提供します。ここで、WireGuard は UDP と INADDR_ANY を使用します。特に198.51.100.3にバインドされていません。これは、ソース0.0.0.0として表示され、発信元IPアドレスの確認がカーネルのルーティングスタックに残されることを意味します。

もし仕える人WireGuardは常に最初のパケットを開始します（代わりに仲間これにより、198.51.100.3の代わりに203.0.113.134が使用されます。ルーティングスタックには特定の項目はありません。IPルール0.0.0.0の場合：IPルール 32765: from 198.51.100.0/24 lookup subnets一致するものはなく、特別なポリシールーティングは適用されません。最後に、UDPパケットはens18を使用して203.0.113.134に進みます。

カーネル実装は、少なくともクエリされたのと同じアドレスを使用し続けるようです。これは信頼できず、UDPサービスを使用したマルチホーミングには特別なサポートが必要です（例：IP_PKTINFO）したがって、アプリケーションで。

WireGuardが追求した結果：

# ip route get from 198.51.100.105 to 192.0.2.233
192.0.2.233 from 198.51.100.105 via 198.51.100.1 dev ens19 table subnets uid 0 
    cache

少なくともトラフィックを最初に開始した実際の結果であれば、次のようになります。

# ip route get from 0.0.0.0 to 192.0.2.233
192.0.2.233 via 203.0.113.1 dev ens18 src 203.0.113.134 uid 0 
    cache

WireGuardトンネルマルチホーミングルーティング自体を実際に変更するには、L4固有のプロトコルルーティングルールを使用できます。

ip rule add iif lo ipproto udp sport 51820 lookup subnets

（iif loローカルで開始された（配信されていない）トラフィックを表す特別な構文であり、インターフェイスに依存しませんlo。）

与える：

# ip route get from 0.0.0.0 ipproto udp sport 51820 to 192.0.2.233
192.0.2.233 via 198.51.100.1 dev ens19 table subnets src 198.51.100.3 uid 0 
    cache

INADDR_ANYをソースとして使用するにもかかわらず、UDPソースポート51820が選択されます。サブネットルーティングテーブル。

Answer 1