文章有截图，若看不清楚，可把页面放大200%进行查看。
环境：测试一个ac下挂ap，ap下的抓包文件传出时，出现题目：
ac的wan口ip是192.168.186.167/24，gw是192.168.186.1，下挂ap的ip是192.168.202.199/24，ac上开子接口192.168.202.1/24，ac上开nat功能。tftp服务器在pc192.168.186.118/24上，和ac的wan口在同一网段。
开始以为是ap的对应目次和文件没有读写权限，chmod 777进行修改后，题目仍旧。
root@IIIoT:/# chmod 777 /tmp
root@IIIoT:/# tftp -p -l /tmp/staonline3.pcap 192.168.186.118
tftp: server error: (768) Access to /tmp/staonline3.pcap denied
root@IIIoT:/# cd /tmp
root@IIIoT:/tmp# ls -l staonline3.pcap
-rw-r--r-- 1 root root 2010 Sep 29 17:16 staonline3.pcap
root@IIIoT:/tmp# chmod 777 staonline3.pcap
root@IIIoT:/tmp# tftp -p -l /tmp/staonline3.pcap 192.168.186.118
tftp: server error: (768) Access to /tmp/staonline3.pcap denied
root@IIIoT:/tmp# tftp -p -l /tmp/staonline3.pcap 192.168.186.118
tftp: server error: (768) Access to /tmp/staonline3.pcap denied
root@IIIoT:/tmp# tftp: server error: (768) Access to /tmp/staonline3.pcap denied
题目还在，决定在tftp服务器pc上和ap上同时抓包，对比查看。tftp的usb网卡接ap同一网段的接口，ap的抓包传到usb网卡的ip上，这样不经过ac的nat功能。
root@IIIoT:~# tcpdump -any -nne -w testtftp.pcap
tcpdump: invalid data link type -nne
root@IIIoT:~# tcpdump -i any -nne -w testtftp.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C894 packets captured
896 packets received by filter
0 packets dropped by kernel
root@IIIoT:~# ls -l *pcap
-rw-r--r-- 1 root root 85651 Sep 26 18:45 staonline.pcap
-rw-r--r-- 1 root root 111110 Sep 29 20:24 testtftp.pcap
root@IIIoT:~# tftp -pl testtftp.pcap 192.168.202.202 传出ap上抓包文件
ap上抓包文件表现如下：只有客户端发出write请求消息，没有后续消息
tftp服务器上抓包表现如下：
tftp服务器发出ack，收到ac发来的destnation port unreachable的消息。
查看icmp的目标不可达消息
发现源地址ac的wan口地址，而目标地址是tftp服务器的地址，而且ttl是64，表示是ac直接发出，而不是经过转接的icmp消息。
对应ap的抓包，ack并没有收到，而且也没有icmp消息发出，据此判定ac直接回的目标端口不可达。
缘故原由分析，ac没有端口alg功能，对tftp协议，后续消息会改变端口发来，而ac的conntrack记录表的五元组里没有对应的表项，导致ac直接回icmp端口不可达项。
conntrack和nat的原理：
数据进入路由器的处理流程：
数据入站，要先查conntrack表里是否有对应的连接记录，没用的话要创建一个新的记录。有的话，符合reply的要进行对应处理。
内网收包：
- 数据包进入Hook（例如ip_nat_out）函数后，进行规则匹配
- 如果全部match都匹备，则进行SNAT模块的动作，即snat的target模块
- 源地址转换的规则一般是…… -j SNAT –to X.X.X.X，SNAT用规则中预设的转换后地址X.X.X.X，修改连接跟踪表中的reply tuple（缘故原由：当数据包进入连接跟踪后，会创建一个tuple以及相应的reply tuple，而回程应答的数据包，会查找与之匹配的reply tuple，——对于源地址转换而言，应答包中的目标地址，将是转换后的地址，而不是真实的源地址，以是，为了让应答的数据包能找到对应的reply tuple，很天然地，NAT模块应该修改reply tuple中的目标地址为snat之前的源地址，以使应答数据包能找到属于本身最终目标地址）
- 接着，修改数据包的来源的地址，将它替换成reply tuple中的相应地址，即规则中预设的地址，将其发送出去
- 对于回来的数据包，应该能在状态跟踪表中，查找与之对应的reply tuple，也就能顺藤摸瓜地找到原始的tuple中的信息，将应答包中的目标地址改回来，这样，整个数据传送就得以顺利转发了
一个路由器的conntrack范例：
路由器的内网接口ip是192.168.100.3，wan口是pppoe接口，得到ip是219.145.1.240，访问外网要用pppoe得到ip进行snat转换。用内网的装备192.168.209.201进行访问。
这个范例里记录内网收到的一个访问路由器本身的内网接口ip地址，另一个访问外网的网页443端口，都天生的reply回包的盼望源ip和目标ip，以及协议类型和状态，是否snat和dnat的类型，收发的包数等信息。出包，进行snat转换，把源地址转换为路由器wan口地址后发出，同时记录conntrack表项的reply值。
wan口收到回包查询conntrack表项，符合reply表项，而且有snat记录的表项，要先进行转换，把目标地址改成source里的源地址，然后进行路由判定，发现是内网地址，符合转发forward条件，就再次进行路由判定后，由内网接口发出。
对应该例，conntrack表里
udp
source:192.168.202.199:42850 > 192.168.186.118:69
reply : 192.168.186.118:69 > 192.168.186.167:42850
但ftp服务器192.168.186.118的ack消息用的是udp协议：
source:192.168.186.118:50767 > 192.168.186.167:42850
这在conntrack表里查不到，就创建一个新记录，目标ip是ac的wan口地址，路由判定后是input处理，ac上没用打开42850这个端口，就按output链处理，发出端口不可达消息。
tftp对路由器的alg要求：
tftp协议的特点，默认服务器打开69端口，客户端使用一个源端口a去连接服务器的69端口，而协议后向确认消息和数据传输的源端口却不是69，而是一个随机端口b，路由器不打开alg功能，会导致后向确认消息无法到达路由器下挂的客户端装备，导致传输失败。
全部要求路由器必须对后向确认消息和数据传输消息携带的目标端口打开dnat功能，让访问a端口的消息可以或许回到客户端，这样确认和数据包才华到达客户端。
这是一个内网tftp写和读文件的过程抓包，可看到端口的变化
测试一下，关闭ac的nat功能，发现重新测试，文件传送成功。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
