PF NAT 与 链路聚合（LACP）问题
系统环境：FreeBSD amd64 10.2网络环境：4网卡+二层交换
实践过程：
1、bsd机器上4个网卡，做LACP链路聚合，创建lagg0和lagg1，分别绑定两个网卡；
2、二层交换上做两个聚合，分别对应lagg0和lagg1；
3、lagg0为wan口，lagg1为lan口，lagg1通过子接口绑定多个子网网关；
lagg0的上游网关：192.168.22.1
lagg0的ip是：192.168.22.254
lagg1的绑定的网段是：169.254.0.0/16
4、bsd机器上启用gateway、pf和ip_forward，pf的规则只一条
nat on lagg0 from lagg1:network to any -> (lagg0)
问题表现：
1、从lagg1下属任何机器都能ping通lagg0，但是ping不同lagg0的上游网关。
2、上tcpdump，抓子网某一机器数据：tcpdump host 169.254.23.2
从结果来看，icmp包只有两种：
169.254.23.2 指向 169.254.23.1
192.168.22.254 指向 192.168.22.1
没有从上游网关到子网机器的返回数据。
换用ipf、ipfw的natd均是如此，无奈。
是否NAT不能作用于lagg设备？google也没找到类似的案例。 ipfw确定不行，ipf没印象了，pf要开sync才可以。 根本的原因在于：做NAT的时候，有个地址转换列表，每个机器都各不相同。
如果一个内网ip1对外网ip2的访问，每一次走了NAT设备A，于是在A上留下了地址转换的状态表；
但是回来的时候走了NAT设备B，B发现没有这个转换，于是便把包扔掉了。
所以关键在于两个NAT机器之间地址转换状态表要同步，所以pf就有了那个sync的选项。
ipfw目前还没有这个选项，但是前几天有个网友发了一个帖子，说DragonFly正在做这个功能。 本帖最后由 fzfh 于 2016-03-27 23:39 编辑
哦，非常感谢楼上的，竟然要加SYNC，还真不知道。我是通过kld来加载的pf，看来不能偷懒，编过内核才行。
谢了，明天就加上试试看。
刚刚简单搜索了一下，pfsync作用与carp设备，对lagg设备同样适用吗？疑问。 回复 4# fzfh
不好意思，我没仔细看你的环境，一目十行的看，以为是carp了。
你是做了两个lagg，分别接内网和外网，NAT设备是一个，这种情况下，应该不需要sync。
你应该在lagg0和lagg1上面分别抓包，看一下数据包到底到哪儿了，并且在lagg0上面，应该抓目的IP，因为源IP已经变了。
本帖最后由 fzfh 于 2016-03-29 01:03 编辑
回复 5# lsstarboy
好，感谢回复。抓了包看不明白再来。 本帖最后由 fzfh 于 2016-03-29 01:03 编辑
tcpdump分别在lagg0和lagg1上抓了包，在wireshark中分析，针对上述的ping过程(169.254.21.2 ping 192.168.22.1)，简单总结一下：
在lagg0上，有lgg0的ip和ping的目标ip的icmp请求和回应包；
在lagg1上，只有lagg1子网客户机的icmp请求包，无回应包。
tcpdump抓取的文件如下：
22.1.cap是lagg0的抓包数据，抓包命令:tcpdump -i lagg0 -vv -c 40 host 192.168.22.1;
21.2.cap是lagg1的抓包数据，抓包命令:tcpdump -i lagg1 -vv -c 40 host 169.254.21.2;
对于pf的nat过程: 169.254.22.1->192.168.22.9->192.168.22.1 已OK，icmp的回应信息192.168.22.1->192.168.22.9也ok，但192.168.22.9->169.254.21.2不通，找不出来原因。还得麻烦各位大大帮忙分析一下原因，谢谢。 本帖最后由 fzfh 于 2016-03-29 13:28 编辑
今天灵机一动，想起来NAT规定的内网IP段不包含169.254.0.0/16网段，然后把内网网段修改为RFC1918规定的内网网段，然后一下子没有问题了。
但是，针对应用修改大量的IP，怎么想都不划算。
这个算不算BUG恩？按道理讲，NAT设备已经屏蔽了所有的内网IP信息，这个与内网使用那个网段应该没有关系，为什么会出这个问题呢？
是PF，IPF的代码引起的？还是FreeBSD自身的严格规则限定的？
如何才能解除NAT对RFC1918定义的内网网段的限制？
linux的iptables没有这个问题。 回复 7# fzfh
说明NAT功能正常，内网不能正确返回到客户机，应该是路由不正常，先检查路由表。
netstat -nr
回复 8# fzfh
不是FreeBSD的bug，跟内网是不是私有网段没关系。
你可以从169.254.21.1上面ping 169.254.21.2看看通不通，这段是arp，可以再看一下arp信息。
页:
[1]
2