PF NAT 與 鏈路聚合（LACP）問(wèn)題

fzfh

系統(tǒng)環(huán)境：FreeBSD amd64 10.2
網(wǎng)絡(luò)環(huán)境：4網(wǎng)卡+二層交換
實(shí)踐過(guò)程：
1、bsd機(jī)器上4個(gè)網(wǎng)卡，做LACP鏈路聚合，創(chuàng)建lagg0和lagg1，分別綁定兩個(gè)網(wǎng)卡；
2、二層交換上做兩個(gè)聚合，分別對(duì)應(yīng)lagg0和lagg1；
3、lagg0為wan口，lagg1為lan口，lagg1通過(guò)子接口綁定多個(gè)子網(wǎng)網(wǎng)關(guān)；
     lagg0的上游網(wǎng)關(guān)：192.168.22.1
     lagg0的ip是：192.168.22.254
     lagg1的綁定的網(wǎng)段是：169.254.0.0/16
4、bsd機(jī)器上啟用gateway、pf和ip_forward，pf的規(guī)則只一條
    nat on lagg0 from lagg1:network to any -> (lagg0)


問(wèn)題表現(xiàn)：
1、從lagg1下屬任何機(jī)器都能ping通lagg0，但是ping不同lagg0的上游網(wǎng)關(guān)。
2、上tcpdump，抓子網(wǎng)某一機(jī)器數(shù)據(jù)：tcpdump host 169.254.23.2
     從結(jié)果來(lái)看，icmp包只有兩種：
    169.254.23.2   指向 169.254.23.1
    192.168.22.254 指向 192.168.22.1
    沒(méi)有從上游網(wǎng)關(guān)到子網(wǎng)機(jī)器的返回?cái)?shù)據(jù)。

換用ipf、ipfw的natd均是如此，無(wú)奈。
是否NAT不能作用于lagg設(shè)備？google也沒(méi)找到類似的案例。

lsstarboy

ipfw確定不行，ipf沒(méi)印象了，pf要開(kāi)sync才可以。

lsstarboy

根本的原因在于：做NAT的時(shí)候，有個(gè)地址轉(zhuǎn)換列表，每個(gè)機(jī)器都各不相同。
如果一個(gè)內(nèi)網(wǎng)ip1對(duì)外網(wǎng)ip2的訪問(wèn)，每一次走了NAT設(shè)備A，于是在A上留下了地址轉(zhuǎn)換的狀態(tài)表；
但是回來(lái)的時(shí)候走了NAT設(shè)備B，B發(fā)現(xiàn)沒(méi)有這個(gè)轉(zhuǎn)換，于是便把包扔掉了。

所以關(guān)鍵在于兩個(gè)NAT機(jī)器之間地址轉(zhuǎn)換狀態(tài)表要同步，所以pf就有了那個(gè)sync的選項(xiàng)。
ipfw目前還沒(méi)有這個(gè)選項(xiàng)，但是前幾天有個(gè)網(wǎng)友發(fā)了一個(gè)帖子，說(shuō)DragonFly正在做這個(gè)功能。

fzfh

哦，非常感謝樓上的，竟然要加SYNC，還真不知道。我是通過(guò)kld來(lái)加載的pf，看來(lái)不能偷懶，編過(guò)內(nèi)核才行。
謝了，明天就加上試試看。

剛剛簡(jiǎn)單搜索了一下，pfsync作用與carp設(shè)備，對(duì)lagg設(shè)備同樣適用嗎？疑問(wèn)。

lsstarboy

回復(fù) 4# fzfh

不好意思，我沒(méi)仔細(xì)看你的環(huán)境，一目十行的看，以為是carp了。

你是做了兩個(gè)lagg，分別接內(nèi)網(wǎng)和外網(wǎng)，NAT設(shè)備是一個(gè)，這種情況下，應(yīng)該不需要sync。

你應(yīng)該在lagg0和lagg1上面分別抓包，看一下數(shù)據(jù)包到底到哪兒了，并且在lagg0上面，應(yīng)該抓目的IP，因?yàn)樵碔P已經(jīng)變了。
   

fzfh

回復(fù) 5# lsstarboy
好，感謝回復(fù)。抓了包看不明白再來(lái)。

fzfh

tcpdump分別在lagg0和lagg1上抓了包，在wireshark中分析，針對(duì)上述的ping過(guò)程(169.254.21.2 ping 192.168.22.1)，簡(jiǎn)單總結(jié)一下：
在lagg0上，有l(wèi)gg0的ip和ping的目標(biāo)ip的icmp請(qǐng)求和回應(yīng)包；
在lagg1上，只有l(wèi)agg1子網(wǎng)客戶機(jī)的icmp請(qǐng)求包，無(wú)回應(yīng)包。
tcpdump抓取的文件如下： dumpdata.7z (1.4 KB, 下載次數(shù): 33)

2016-03-29 01:03 上傳

點(diǎn)擊文件名下載附件

22.1.cap是lagg0的抓包數(shù)據(jù)，抓包命令:tcpdump -i lagg0 -vv -c 40 host 192.168.22.1;
21.2.cap是lagg1的抓包數(shù)據(jù)，抓包命令:tcpdump -i lagg1 -vv -c 40 host 169.254.21.2;

對(duì)于pf的nat過(guò)程: 169.254.22.1->192.168.22.9->192.168.22.1 已OK，icmp的回應(yīng)信息192.168.22.1->192.168.22.9也ok，但192.168.22.9->169.254.21.2不通，找不出來(lái)原因。還得麻煩各位大大幫忙分析一下原因，謝謝。

fzfh

今天靈機(jī)一動(dòng)，想起來(lái)NAT規(guī)定的內(nèi)網(wǎng)IP段不包含169.254.0.0/16網(wǎng)段，然后把內(nèi)網(wǎng)網(wǎng)段修改為RFC1918規(guī)定的內(nèi)網(wǎng)網(wǎng)段，然后一下子沒(méi)有問(wèn)題了。
但是，針對(duì)應(yīng)用修改大量的IP，怎么想都不劃算。
這個(gè)算不算BUG恩？按道理講，NAT設(shè)備已經(jīng)屏蔽了所有的內(nèi)網(wǎng)IP信息，這個(gè)與內(nèi)網(wǎng)使用那個(gè)網(wǎng)段應(yīng)該沒(méi)有關(guān)系，為什么會(huì)出這個(gè)問(wèn)題呢？
是PF，IPF的代碼引起的？還是FreeBSD自身的嚴(yán)格規(guī)則限定的？
如何才能解除NAT對(duì)RFC1918定義的內(nèi)網(wǎng)網(wǎng)段的限制？
linux的iptables沒(méi)有這個(gè)問(wèn)題。

lsstarboy

回復(fù) 7# fzfh

說(shuō)明NAT功能正常，內(nèi)網(wǎng)不能正確返回到客戶機(jī)，應(yīng)該是路由不正常，先檢查路由表。

netstat -nr
   

lsstarboy

回復(fù) 8# fzfh


不是FreeBSD的bug，跟內(nèi)網(wǎng)是不是私有網(wǎng)段沒(méi)關(guān)系。

你可以從169.254.21.1上面ping 169.254.21.2看看通不通，這段是arp，可以再看一下arp信息。