私は探していましたが、私の特定の問題に対する答えを見つけることができないようです。今日、プレルーティングの下で次のルールがあります:iifname "br0" udp dport 53 counter dnat to 192.168.22.5:53
ただし、1つの問題があります。IPアドレス192.168.22.5も "br0"にあります。だから手元の問題は、nftablesにこのIPを無視させ、ネット上のポート53(これは私の穴)へのアクセスを許可し、他のすべてのポート53 udpデータをそれにリダイレクトさせるにはどうすればよいですか?
返信を感謝します!
このIPアドレスに一致しないように条件を追加するだけで、NATを最後に実行しません。
iifname "br0" ip saddr != 192.168.22.5 udp dport 53 counter dnat to 192.168.22.5:53
BUT ...クライアントとDNSサーバーの両方が同じLANにある場合、DNSサーバーからクライアントへの応答は直接行われます。たとえば、192.168.22.101のクライアントがgoogleのパブリックリゾルバを使用するように設定されている場合(関連するすべてのプライバシー問題)、次のようになります。
クエリ:192.168.22.101から8.8.8.8-> routed and dnat-ed-> 192.168.22.5
返信:192.168.22.5->ipファミリルールでは認識されないブリッジド(またはルーターではまったく認識されない)-> 192.168.22.101
しかし、192.168.22.101は192.168.22.5ではなく8.8.8.8からの回答を期待しているため、失敗します。
したがって、クエリもsnatする必要があります。パケットがルーターを使用するIPアドレスは問題ありません。ルーターの内部IP(masquerade
)は、ルーターがこのIPを所有しているためです。また、インターネットIP(snat
を使用)は、ルーターを介してルーティングされるためです。 。このためにいくつかのTEST-NET IPを使用することを想像することもできます(例:192.0.2.2):とにかく、IPアドレスがローカルネットワークの外に表示されることはありません。欠点は、DNSサーバーがクエリを行ったIPを識別できないことです。新しいカーネル(今後の5.7または5.8)では、これが本当に重要な場合は iptablesのNETMAPと同等 が使用可能になります。
ここでは、簡単にするためにmasquerade
を使用しましょう。
したがって、次のようなもので作成できる同等のポストルーティングチェーン内で(独自の命名規則に適応してください):
nft add chain ip nat postrouting '{ type nat hook postrouting priority 100; policy accept; }'
ルールは次のようになります。
ip daddr 192.168.22.5 udp dport 53 counter masquerade
DNSサーバーから開始されたリターントラフィックには影響しません。これは、そのconntrackエントリがNEW状態ではなくなり、このnatルールがトラバースされないためです。
以前にbr0からのトラフィックのみに影響を与え、他の場所からは影響を与えたくない場合は、いくつかのオプションがあります。
ソースIPが192.168.22.0/24であり、dnat-edであることを確認します
ip saddr 192.168.22.0/24 ip daddr 192.168.22.5 udp dport 53 ct status dnat counter masquerade
最近の十分なカーネル(> = 5.6)の場合、代わりに着信インターフェース(まだポストルーティング中)でのマッチングで十分です。
iifname "br0" ip daddr 192.168.22.5 udp dport 53 ct status dnat counter masquerade
または、他の用途と競合しない場合は、事前ルーティングと事後ルーティングでマークを使用できます。
事前ルーティング:
iifname "br0" ip saddr != 192.168.22.5 udp dport 53 counter set mark 1 dnat to 192.168.22.5:53
ポストルーティング:
mark 1 counter masquerade
そして最後に、DNSはTCPとUDPを使用するため、tcp dport 53
を使用して同じように適用する必要があります。
ホスト自体から発信されたトラフィックはiifname $outgoing_interface
(ただしiifname lo
)に一致しないため、懸念はありません。