PF NAT 与 链路聚合（LACP）问题

fzfh

系统环境：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也没找到类似的案例。

lsstarboy

ipfw确定不行，ipf没印象了，pf要开sync才可以。

lsstarboy

根本的原因在于：做NAT的时候，有个地址转换列表，每个机器都各不相同。
如果一个内网ip1对外网ip2的访问，每一次走了NAT设备A，于是在A上留下了地址转换的状态表；
但是回来的时候走了NAT设备B，B发现没有这个转换，于是便把包扔掉了。

所以关键在于两个NAT机器之间地址转换状态表要同步，所以pf就有了那个sync的选项。
ipfw目前还没有这个选项，但是前几天有个网友发了一个帖子，说DragonFly正在做这个功能。

fzfh

哦，非常感谢楼上的，竟然要加SYNC，还真不知道。我是通过kld来加载的pf，看来不能偷懒，编过内核才行。
谢了，明天就加上试试看。

刚刚简单搜索了一下，pfsync作用与carp设备，对lagg设备同样适用吗？疑问。

lsstarboy

回复 4# fzfh

不好意思，我没仔细看你的环境，一目十行的看，以为是carp了。

你是做了两个lagg，分别接内网和外网，NAT设备是一个，这种情况下，应该不需要sync。

你应该在lagg0和lagg1上面分别抓包，看一下数据包到底到哪儿了，并且在lagg0上面，应该抓目的IP，因为源IP已经变了。
   

fzfh

回复 5# lsstarboy
好，感谢回复。抓了包看不明白再来。

fzfh

tcpdump分别在lagg0和lagg1上抓了包，在wireshark中分析，针对上述的ping过程(169.254.21.2 ping 192.168.22.1)，简单总结一下：
在lagg0上，有lgg0的ip和ping的目标ip的icmp请求和回应包；
在lagg1上，只有lagg1子网客户机的icmp请求包，无回应包。
tcpdump抓取的文件如下： dumpdata.7z (1.4 KB, 下载次数: 33)

2016-03-29 01:03 上传

点击文件名下载附件

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

今天灵机一动，想起来NAT规定的内网IP段不包含169.254.0.0/16网段，然后把内网网段修改为RFC1918规定的内网网段，然后一下子没有问题了。
但是，针对应用修改大量的IP，怎么想都不划算。
这个算不算BUG恩？按道理讲，NAT设备已经屏蔽了所有的内网IP信息，这个与内网使用那个网段应该没有关系，为什么会出这个问题呢？
是PF，IPF的代码引起的？还是FreeBSD自身的严格规则限定的？
如何才能解除NAT对RFC1918定义的内网网段的限制？
linux的iptables没有这个问题。

lsstarboy

回复 7# fzfh

说明NAT功能正常，内网不能正确返回到客户机，应该是路由不正常，先检查路由表。

netstat -nr
   

lsstarboy

回复 8# fzfh


不是FreeBSD的bug，跟内网是不是私有网段没关系。

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