
答案1
據我所知,由於不可能iptables規則執行後nat/後路由,這是由提供的最後一個鉤子iptables,無法使用iptables捕獲 NAT 後的資料包。
但這在使用時是可能的nftables,自從鉤子優先權是使用者定義的。NFFT的重複語句是直接替換iptables'球座。混合是可以的nftables和iptables只要它們不都進行 NAT(nat 資源很特殊,不能在它們之間正確共享)iptables和nftables)。使用nftables 上的 iptables的版本iptables也會起作用(刷新規則集時應小心),當然僅使用NFFT因為一切都會有效。
這是現成的NFFT具有 NATed LAN 的路由器上的規則集乙太網路1其 WAN 端位於以太坊2,將副本傳送到 LAN 端的 192.168.0.3。就像描述的那樣OP的其他問題。放入某個名為forwireshark.nft並使用以下命令“加載” nft -f forwireshark.nft
:
table ip forwireshark {
chain postnat {
type filter hook postrouting priority 250; policy accept;
oif eth2 counter dup to 192.168.0.3 device eth1
}
}
這裡重要的是值 250 被選為高於iptables'NF_IP_PRI_NAT_SRC
(100)。
以下是當 ping 主機ping -c1 8.8.8.8
在一段時間不活動後執行的操作時,通常會收到wireshark主機的資訊(請注意來自「錯誤」IP的奇怪ARP 請求,在某些系統上預設情況下可能不會接受該請求):
root@ns-wireshark:~# tcpdump -e -n -s0 -p -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:06:03.074142 82:01:54:27:4d:d7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.0.1 tell 192.168.0.2, length 28
21:06:03.074301 9a:80:fb:e6:6a:0a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.0.3 tell 140.82.118.4, length 28
21:06:03.074343 7e:0a:6c:12:00:61 > 9a:80:fb:e6:6a:0a, ethertype ARP (0x0806), length 42: Reply 192.168.0.3 is-at 7e:0a:6c:12:00:61, length 28
21:06:03.074387 9a:80:fb:e6:6a:0a > 7e:0a:6c:12:00:61, ethertype IPv4 (0x0800), length 98: 140.82.118.4 > 8.8.8.8: ICMP echo request, id 1633, seq 1, length 64
我不知道順序的理由重整/後期佈線和nat/後路由。無論如何,這是一部分iptables' 的局限性,因為在nftables,除了相當於粉碎/輸出這是一個特殊的輸入路線用於重新路由的鉤子,所有其他等效用法碾壓是一部分類型過濾器: 確實沒有單獨的碾壓不再打字了。能夠選擇優先順序可以做更多的事情。