引言
iptables的规则定义在PREROUTING、INPUT、FORWARD、OUTPUT与POSTROUTING五个链中，本文实践与记录了容器服务（docker daemon设置userland-proxy=true、userland-proxy=false）与非容器服务两种情况下，本机上通过ip地址与127.0.0.1访问服务，数据包经过的链与链的次序。
实践环境
Centos7.2 + Docker1.12.6
接收udp协议数据包的程序内容为：
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(('0.0.0.0', 9999))
print 'Bind udp on 9999...'
while 1:
# 接收数据:
data, addr = s.recvfrom(1024)
print 'addr: {0}, data: {1}'.format(addr, data)
关闭主机firewalld：systemctl stop firewalld
设置selinux为Permissive模式：setenforce 0
主机IP：192.168.84.75
主机上docker0网桥信息：
实践
本机上执行 echo mac | nc -u 192.168.84.75 8000 访问容器服务
一、
/etc/docker/daemon.json内容：
{
"userland-proxy": true
}
主机filter表规则:
docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15创建容器后，filter表规则：
-
验证没有经过PREROUTING链
在mangle表的PREROUTING链中插入规则iptables -t mangle -A PREROUTING -p udp -m udp --dport 8000 -j MARK --set-xmark 0x1/0xffffffff，表示对udp协议、目的端口为8000的数据包做值为1的标志。如果echo mac | nc -u 192.168.84.75 8000产生的数据包经过PREROUTING链，则会匹配到这条规则。多次执行 echo mac | nc -u 192.168.84.75 8000 命令后，发现数据包没有匹配到规则，因此判断echo mac | nc -u 192.168.84.75 8000产生的数据包不经过PREROUTING链。由此也可得出数据包不会经过INPUT链与FORWARD链。接着做实践验证，若下面2、3分别验证数据包没有经过INPUT链与FORWARD链，则也验证了数据包没有经过PREROUTING链。 -
验证没有经过INPUT链
首先删除步骤1中添加的规则：iptables -t mangle -D PREROUTING 1
在filter表的INPUT链中添加规则：iptables -t filter -I INPUT -p udp -m udp -j DROP，表示丢弃udp协议的数据包，如果echo mac | nc -u 192.168.84.75 8000的数据包经过INPUT链，则会被添加的规则匹配，进而被丢弃。实践发现，数据包正常达到容器内的程序，打印结果：addr: ('192.168.84.75', 39251), data: mac，因此验证echo mac | nc -u 192.168.84.75 8000产生的数据包不经过INPUT链 -
验证没有经过FORWARD链
首先删除步骤2中添加的规则：iptables -t filter -D INPUT 1
在filter表的FORWARD链中添加规则：iptables -t filter -I FORWARD -p udp -m udp -j DROP，表示丢弃udp协议的数据包，因此echo mac | nc -u 192.168.84.75 8000产生的数据包如果经过FORWARD链则会被丢弃。实践得知，数据包正常达到容器内的程序，打印结果：addr: ('192.168.84.75', 60556), data: mac，因此验证echo mac | nc -u 192.168.84.75 8000产生的数据包不经过FORWARD链。另外，如果将绑定8000端口的docker-proxy进程kill掉，本机上执行 echo mac | nc -u 192.168.84.75 8000 ，数据包依然能够到达容器内的程序，打印结果：addr: ('192.168.84.75', 44117), data: mac。经过实践得知，数据包依然只经过OUTPUT链与POSTROUTING链，而并没有经过PREROUTING、INPUT与FORWARD链。
因此，在本机上通过 echo mac | nc -u 192.168.84.75 8000 产生的数据包只会经过OUTPUT与POSTROUTING链，不会经过PREROUTING、INPUT与FORWARD链。
二、
/etc/docker/daemon.json内容：
{
"userland-proxy": false
}
filter表规则：
docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15创建完容器后，filter表规则：
和上述操作一样，在INPUT链与FORWARD链处添加对udp协议包的DROP操作，如果数据包依然能够到达容器内的程序，则说明数据包没有经过INPUT链与FORWARD链，进而也可证明数据包没有经过PREROUTING链。
在INPUT链、FORWARD链处添加对udp数据包的DROP规则
本机上执行 echo mac | nc -u 127.0.0.1 8000 访问容器服务
一、
/etc/docker/daemon.json内容：
{
"userland-proxy": true
}
filter表规则：
docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15创建完容器后，filter表规则：
对比可发现，数据包经过了OUTPUT与POSTROUTING链，没有经过PREROUTING链、INPUT链与FORWARD链。但与之前不同的是每次执行 echo mac | nc -u 127.0.0.1 8000 后，OUTPUT链与POSTROUTING链默认策略匹配到的是两个packet，难道是数据包经过了两次OUTPUT与POSTROUTING链？如果是两次那怎么会不经过PREROUTING链、INPUT链、FORWARD链其中的一些呢？带着这个疑问，开始实践。
同样在mangle表的PREROUTING链中添加规则 iptables -t mangle -I PREROUTING -p udp -m udp -j MARK --set-xmark 0x1/0xffffffff，表示对udp协议的数据包做值为1的标志，如果 echo mac | nc -u 127.0.0.1 8000产生的数据包经过PREROUTING链，则会匹配到这条规则。
实践可发现，每执行一次 echo mac | nc -u 127.0.0.1 8000的命令，上述添加的规则均会匹配到对应的数据包，因此可证明数据包经过PREROUTING链。
去除mangle表PREROUTING链中添加的规则 iptables -t mangle -D PREROUTING 1，然后在filter表的INPUT链、FORWARD链处添加对udp协议、 目的端口为8000的数据包的DROP规则：
在数据包被INPUT链的规则 iptables -t filter -I INPUT -p udp -m udp --dport 8000 -j DROP 匹配的同时，主机的lo、docker0以及容器设备veth900a164抓包的结果如下：
tcpdump -i lo -nn -vv
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
16:09:22.430865 IP (tos 0x0, ttl 64, id 55007, offset 0, flags [DF], proto UDP (17), length 32)
127.0.0.1.46761 > 127.0.0.1.8000: [bad udp cksum 0xfe1f -> 0x5b7e!] UDP, length 4
tcpdump -i docker0 -nn -vv
tcpdump: listening on docker0, link-type EN10MB (Ethernet), capture size 262144 bytes
无内容
tcpdump -i veth900a164 -nn -vv
tcpdump: listening on veth900a164, link-type EN10MB (Ethernet), capture size 262144 bytes
无内容
可知数据包在进入INPUT链之前经过了lo设备，至此可知数据包经过的顺序为：packet ---> xxx ---> lo设备 ---> PREROUTING ---> INPUT ---> 用户空间（docker-proxy）---> xxx。可数据包又是从哪里进入到lo设备的，从用户空间出来又经过了哪些链呢（有iptables相关知识的会知道此处数据包经过OUTPUT ---> POSTROUTING流出，下面实践中也会验证）？猜测数据包应该是经过OUTPUT链，然后经过POSTROUTING链进入到lo设备，数据包从用户空间出来后也是经过OUTPUT与POSTROUTING链，然后依据路由被发往下一个设备。lo设备接收到的数据包的源地址、源端口与目的地址、目的端口为127.0.0.1.port（port随机分配） > 127.0.0.1.8000，因此在nat表的OUTPUT链与POSTROUTING链中分别添加规则：
iptables -t nat -I OUTPUT -p udp -m udp -s 127.0.0.1/32 -d 127.0.0.1/32 --dport 8000 -j DNAT --to-destination 127.0.0.1:8000：将源地址为127.0.0.1、目的地址为127.0.0.1、目的端口为8000、udp协议的数据包的目的地址、目的端口修改为127.0.0.1.8000；发往lo设备的数据包只要经过OUTPUT链，则会被此条规则匹配，进而验证流向lo设备的数据包经过OUTPUT链。第二条规则
iptables -t nat -I POSTROUTING -p udp -m udp -s 127.0.0.1/32 --dport 8000 -j SNAT --to-source 192.168.84.75：将源地址为127.0.0.1、目的端口为8000、udp协议的数据包的源地址修改为主机ip 192.168.84.75；规则对从OUTPUT链流出的数据包能够匹配到，目的是想要验证流向lo设备的数据包127.0.0.1.port（port随机分配） > 127.0.0.1.8000经过OUTPUT链后，流入POSTROUTING链，然后流向lo设备。
执行echo mac | nc -u 127.0.0.1 8000前后，nat表规则对比：
packet ---> OUTPUT ---> POSTROUTING ---> lo设备；默认规则匹配到数据包可验证：packet ---> 用户空间（docker-proxy）---> OUTPUT ---> POSTROUTING。lo设备接收的数据包为：tcpdump -i lo -nn -vvtcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
16:45:39.027483 IP (tos 0x0, ttl 64, id 55014, offset 0, flags [DF], proto UDP (17), length 32)
192.168.84.75.44276 > 127.0.0.1.8000: [bad udp cksum 0x9412 -> 0xcf40!] UDP, length 4
至此，依据实验的结果可知数据包流经的顺序为：packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 用户空间（docker-proxy）---> OUTPUT ---> POSTROUTING。echo mac | nc -u 127.0.0.1 8000产生的数据包确实经过了两次OUTPUT链与POSTROUTING链。
二、
/etc/docker/daemon.json内容：
{
"userland-proxy": false
}
filter表规则：
docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15创建完容器后，filter表规则：
分别在filter表的INPUT链与FORWARD链处添加对udp协议、目的端口为8000的数据包的DROP规则
接收数据包的程序直接运行在主机上（非容器方式），实践数据包经过的设备以及链的次序
一、在主机上执行 echo mac | nc -u 127.0.0.1 9999
关闭firewalld：systemctl stop firewalld
设置selinux为Permissive模式：setenforce 0
路由信息：
对比可发现，与上述实践一中不同的是每执行一次 echo mac | nc -u 127.0.0.1 9999发送数据包后，OUTPUT链与POSTROUTING链的默认策略匹配到的不再是两个packet，而是一个。于是猜测数据包流经的顺序为：
packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 程序（用户空间）
echo mac | nc -u 127.0.0.1 9999发送的数据包源地址、端口与目的地址、端口为：127.0.0.1.port > 127.0.0.1.9999。因此在OUTPUT链处添加规则 iptables -t nat -I OUTPUT -p udp -m udp --dport 9999 -j DNAT --to-destination 192.168.84.75:9999，表示修改udp协议、目的端口为9999数据包的目的地址为主机的ip地址192.168.84.75，如果数据包先经过OUTPUT链，则从OUTPUT链流出的数据包的源地址、端口与目的地址、端口则会变为：127.0.0.1.port > 192.168.84.75.9999。假设数据包紧接着流入POSTROUTING链，于是在POSTROUTING链中添加规则 iptables -t nat -I POSTROUTING -p udp -m udp -d 192.168.84.75 --dport 9999 -j SNAT --to-source 192.168.84.75，表示修改udp协议、目的地址为192.168.84.75、目的端口为9999的数据包的源地址为192.168.84.75，如果数据包不是从OUTPUT链流出然后进入POSTROUTING链的，则这条规则将匹配不到数据包。数据包流经的顺序若为假设的OUTPUT ---> POSTROUTING，则从POSTROUTING流出的数据包的源地址、源端口与目的地址、目的端口变为：192.168.84.75.port > 192.168.84.75.9999。这时分别在mangle表的PREROUTING链中添加规则 iptables -t mangle -I PREROUTING -p udp -m udp -s 192.168.84.75 -d 192.168.84.75 --dport 9999 -j MARK --set-xmark 0x1/0xffffffff，表示对udp协议、源地址与目的地址均为192.168.84.75、目的端口为9999的数据包做值为1的标志；在filter表的INPUT链中添加规则 iptables -t filter -I INPUT -s 192.168.84.75 -d 192.168.84.75 -j DROP，表示对源地址与目的地址均为192.168.84.75的数据包执行丢弃操作。此时如果lo设备抓不到类型为192.168.84.75.port > 192.168.84.75.9999的数据包，则说明数据包先经过INPUT链（在此处被丢弃，因此没有数据包发往lo设备），然后才流入lo设备；反之，则说明先经过lo设备，然后再进入INPUT链中。
tcpdump -i lo -nn -vvtcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:55:11.653981 IP (tos 0x0, ttl 64, id 55007, offset 0, flags [DF], proto UDP (17), length 32)
192.168.84.75.46225 > 192.168.84.75.9999: [bad udp cksum 0x2a05 -> 0x29e2!] UDP, length 4mangle表对比：
packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 程序（用户空间）二、在本机上执行 echo mac | nc -u 192.168.84.75 9999
采用上述相同的方式验证可知，数据包流经的顺序同样为：packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 程序（用户空间）
总结
- 通过ip访问容器服务，不管userland-proxy=true 还是 userland-proxy=false，数据包仅经过OUTPUT与POSTROUTING链
- 通过127.0.0.1访问容器服务且userland-proxy=true，数据包经过的链以及次序为：
packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 用户空间（docker-proxy）---> OUTPUT ---> POSTROUTING - 通过127.0.0.1访问容器服务，当userland-proxy=false时，数据包仅经过OUTPUT与POSTROUTING链
- 通过ip或127.0.0.1访问非容器服务（直接运行在主机上），数据包经过的链以及次序：
packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 程序（用户空间）
上述记录了访问容器服务与宿主机服务数据包经过的链以及链的次序的情况，这些基础工作为后续研究Docker SNAT与DNAT提供了很大的帮助，后面会将Docker SNAT与DNAT的实践继续分享给大家，恳请大家对本文实践提出改进意见，希望与大家一起学习，一起研究。
