本地访问Docker容器的数据包经过的链与链的次序的研究

引言

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表规则:

主机nat表规则： 创建容器python：docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15
创建容器后，filter表规则： nat表规则： 执行 echo mac | nc -u 192.168.84.75 8000 命令前后，nat表规则对比： 经过多次实践的对比得知，echo mac | nc -u 192.168.84.75 8000 产生的数据包只经过OUTPUT与POSTROUTING链，下面做实践验证数据包没有经过PREROUTING链、INPUT链、FORWARD链。

1. 验证没有经过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链。

2. 验证没有经过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链

3. 验证没有经过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表规则：

nat表规则： 创建容器python：docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15
创建完容器后，filter表规则： nat表规则： 执行 echo mac | nc -u 192.168.84.75 8000 命令，nat表规则对比： 经过多次实践的对比得知，echo mac | nc -u 192.168.84.75 8000 产生的数据包只经过OUTPUT与POSTROUTING链，下面做实验验证数据包没有经过PREROUTING链、INPUT链、FORWARD链

和上述操作一样，在INPUT链与FORWARD链处添加对udp协议包的DROP操作，如果数据包依然能够到达容器内的程序，则说明数据包没有经过INPUT链与FORWARD链，进而也可证明数据包没有经过PREROUTING链。

在INPUT链、FORWARD链处添加对udp数据包的DROP规则

实践发现通过echo mac | nc -u 192.168.84.75 8000发送的数据包依然能够到达容器，程序的输出结果：addr: ('172.17.0.1', 49987), data: mac，因此可证明数据包没有经过INPUT、FORWARD链，进而也证明了数据包没有经过PREROUTING链。另外需要注意的是：当设置userland-proxy=false时，docker不会再为每个容器创建docker-proxy进程，同时会在nat表的POSTROUTING链中添加一条规则： 程序接收到的数据包的源地址被修改为172.17.0.1就是因为匹配到了这个规则。

本机上执行 echo mac | nc -u 127.0.0.1 8000 访问容器服务

一、
/etc/docker/daemon.json内容：

{
  "userland-proxy": true
}

filter表规则：

nat表规则： 创建容器python：docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15
创建完容器后，filter表规则： nat表规则： 执行 echo mac | nc -u 127.0.0.1 8000 前后，nat表规则对比： ......
对比可发现，数据包经过了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 发送数据包，观察mangle表的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规则：

执行 echo mac | nc -u 127.0.0.1 8000，filter表规则前后对比： 数据包没有到达容器内，在INPUT链被DROP掉了，可知 echo mac | nc -u 127.0.0.1 8000 产生的数据包经过了INPUT链，没有经过FORWARD链。进一步验证，去除INPUT链中的规则，重新执行echo mac | nc -u 127.0.0.1 8000，容器内程序能够接收到数据包，说明数据包没有经过FORWARD链。

在数据包被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表规则对比：

由上图可知，OUTPUT链与POSTROUTING链添加的规则以及默认的策略均匹配到数据包。添加的规则匹配到数据包可验证：packet ---> OUTPUT ---> POSTROUTING ---> lo设备；默认规则匹配到数据包可验证：packet ---> 用户空间（docker-proxy）---> OUTPUT ---> POSTROUTING。lo设备接收的数据包为：
tcpdump -i lo -nn -vv
tcpdump: 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表规则：

nat表规则： 创建容器：docker run -itd --name python --network bridge -p 8000:9999/udp --entrypoint bash python:2.7.15
创建完容器后，filter表规则： nat表规则： 执行echo mac | nc -u 127.0.0.1 8000前后，nat表规则对比： 可知，数据包经过了OUTPUT链与POSTROUTING链。实践验证数据包是否经过PREROUTING、INPUT与FORWARD链。

分别在filter表的INPUT链与FORWARD链处添加对udp协议、目的端口为8000的数据包的DROP规则

执行echo mac | nc -u 127.0.0.1 8000发送数据包，容器内程序接收到数据包，打印结果为：addr: ('172.17.0.1', 53798), data: mac。可验证数据包没有经过INPUT链与FORWARD链，进而验证数据包也没有经过PREROUTING链。

接收数据包的程序直接运行在主机上（非容器方式），实践数据包经过的设备以及链的次序

一、在主机上执行 echo mac | nc -u 127.0.0.1 9999
关闭firewalld：systemctl stop firewalld
设置selinux为Permissive模式：setenforce 0

路由信息：

filter表规则： nat表规则： mangle表规则： 执行 echo mac | nc -u 127.0.0.1 9999前后，nat表信息对比： ......
对比可发现，与上述实践一中不同的是每执行一次 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链中。

执行 echo mac | nc -u 127.0.0.1 9999 前后，nat表对比： tcpdump -i lo -nn -vv
tcpdump: 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 4
mangle表对比： filter表对比： 上述结果可知，数据包匹配到了OUTPUT与POSTROUTING链中的规则，lo设备抓到的数据包类型为：192.168.84.75.46225 > 192.168.84.75.9999，mangle表的PREROUTING链的规则成功匹配到数据包，INPUT链中的规则丢弃了数据包，因此证明数据包流经的顺序为：packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 程序（用户空间）

二、在本机上执行 echo mac | nc -u 192.168.84.75 9999
采用上述相同的方式验证可知，数据包流经的顺序同样为：packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 程序（用户空间）

总结

1. 通过ip访问容器服务，不管userland-proxy=true 还是 userland-proxy=false，数据包仅经过OUTPUT与POSTROUTING链
2. 通过127.0.0.1访问容器服务且userland-proxy=true，数据包经过的链以及次序为：packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 用户空间（docker-proxy）---> OUTPUT ---> POSTROUTING
3. 通过127.0.0.1访问容器服务，当userland-proxy=false时，数据包仅经过OUTPUT与POSTROUTING链
4. 通过ip或127.0.0.1访问非容器服务（直接运行在主机上），数据包经过的链以及次序：packet ---> OUTPUT ---> POSTROUTING ---> lo设备 ---> PREROUTING ---> INPUT ---> 程序（用户空间）

上述记录了访问容器服务与宿主机服务数据包经过的链以及链的次序的情况，这些基础工作为后续研究Docker SNAT与DNAT提供了很大的帮助，后面会将Docker SNAT与DNAT的实践继续分享给大家，恳请大家对本文实践提出改进意见，希望与大家一起学习，一起研究。