iptables防火墙基本概念及数据流程和docker防火墙配置实例

防火墙相关概念

从逻辑上讲，防火墙可以大体分为主机防火墙和网络防火墙。

主机防火墙：针对于单个主机进行防护。
网络防火墙：往往处于网络入口或边缘，针对于网络入口进行防护，服务于防火墙背后的本地局域网。

网络防火墙和防火墙并不冲突，可以理解为，网络防火墙主外（集体），主机防火墙主内（个人）

从物理上讲，防火墙可以分为硬件防火墙和软件防火墙。

硬件防火墙：在硬件级别实现部分防火墙功能，另一部分功能基于软件实现，性能高，成本高。
软件防火墙：应用软件处理逻辑运行于通用硬件平台之上的防火墙，性能低，成本低。

IPTABLES的表与链

iptables是linux自带的一款开源的内核级基于数据包过滤的防火墙。利用iptables可以实现诸如数据包过滤、转发等功能。

iptables包含表，表中包含链，链中包含规则。（规则指的是一条条用于过滤数据包的语句）

iptables是按照规则来办事的，规则其实就是网络管理员预定义的条件，规则一般的定义为"如果数据包头符合这样的条件，就这样处理这个数据包"。规则存储在内核空间的信息包过滤表中，这些规则分别指定了源地址、目的地址、传输协议（如TCP、UDP、ICMP）和服务类型（如HTTP、FTP和SMTP）等。当数据包与规则匹配时，iptables就根据规则所定义的方法来处理这些数据包，如放行（accept）、拒绝（reject）和丢弃（drop）等。

配置防火墙的主要工作就是添加、修改和删除这些规则。具体可查看此文档：https://blog.csdn.net/biao0309/article/details/106951023

数据经过防火墙的流程

如下图，当请求主机的某个服务时，需要经过iptables中的匹配规则，由上到下层层过滤。

Docker防火墙相关

举个例子，通过docker启用了一个Mysql服务，这个服务为了安全，只允许A服务器访问，需要设置防火墙

# 禁止全部
iptables -P INPUT DROP# 允许A服务器访问
iptables -A INPUT -p tcp –s 192.168.2.1 -j ACCEPT

但此时会发现规则并不生效，这个容器服务依旧是对所有人开放，那么这是怎么了？

实际上，Docker容器不是主机服务。它们依赖于主机中的虚拟网络，并且主机充当该网络的网关。对于网关，路由流量不是由INPUT表处理，而是由FORWARD表处理，这会使设置的规则无效。

实际上，Docker守护程序在开始做有关容器网络连接的时候，会创建许多iptables规则。特别是，创建了DOCKER表来处理有关容器的规则，将流量从FORWARD表转发到此新表。

Docker在FORWARD链中，还额外提供了自己的链，以实现bridge网络之间的隔离与通信。

docker链

Docker在iptables的filter表中的链
在2015.12之前，Docker只额外提供了DOCKER链。

在此之后，直到Docker 17.06.0（2017.6）之前的版本中，Docker提供了如下2个链：DOCKER、DOCKER-ISOLATION

在Docker 17.06.0（2017.6）及之后，Docker 18.03.1（2018.4）及之前的版本中，Docker提供了如下3个链：DOCKER、DOCKER- ISOLATION、DOCKER-USER
Docker的DOCKER链
仅处理从宿主机到docker0的IP数据包。
Docker的DOCKER-ISOLATION链
可以看到，为了隔离在不同的bridge网络之间的容器，Docker提供了两个DOCKER-ISOLATION阶段实现。

DOCKER-ISOLATION-STAGE-1链过滤源地址是bridge网络（默认docker0）的IP数据包，匹配的IP数据包再进入DOCKER-ISOLATION-STAGE-2链处理，不匹配就返回到父链FORWARD。

在DOCKER-ISOLATION-STAGE-2链中，进一步处理目的地址是bridge网络的IP数据包，匹配的IP数据包表示该IP数据包是从一个bridge网络的网桥发出，到另一个bridge网络的网桥，这样的IP数据包来自其他bridge网络，将被直接DROP；不匹配的IP数据包就返回到父链FORWARD继续进行后续处理。
Docker的DOCKER-USER链
Docker启动时，会加载DOCKER链和DOCKER-ISOLATION（现在是DOCKER-ISOLATION-STAGE-1）链中的过滤规则，并使之生效。

docker添加规则

如果用户要补充Docker的过滤规则，建议追加到DOCKER-USER链。DOCKER-USER链中的过滤规则，将先于Docker默认创建的规则被加载，从而能够覆盖Docker在DOCKER链和DOCKER-ISOLATION链中的默认过滤规则。

例如，Docker启动后，默认任何外部source IP都被允许转发，从而能够从该source IP连接到宿主机上的任何Docker容器实例。如果只允许一个指定的IP访问容器实例，可以插入路由规则到DOCKER-USER链中，从而能够在DOCKER链之前被加载。示例如下：

# 只允许192.168.1.1访问容器
iptables -A DOCKER-USER -i docker0 ! -s 192.168.1.1 -j DROP# 只允许192.168.1.0/24网段中的IP访问容器
iptables -A DOCKER-USER -i docker0 ! -s 192.168.1.0/24 -j DROP# 只允许192.168.1.1-192.168.1.3网段中的IP访问容器（需要借助于iprange模块）
iptables -A DOCKER-USER -m iprange -i docker0 ! --src-range 192.168.1.1-192.168.1.3 -j DROP

禁用端口示例

启动了容器数据库Mysql服务，内部端口3306，映射端口3307

根据国际惯例，需要对端口做限制，数据库只能被指定服务器访问，按照经验，禁止全部访问3307

# 禁用全部访问端口3307
iptables -I DOCKER-USER -p tcp –dport 3307 -j DROP# 同时允许一个服务器访问本机3307端口
iptables -I DOCKER-USER -p tcp –s 192.168.3.1 –dport 3307 -j ACCEPT

奇怪的事情发生了，经验出了问题，依旧是可以全部IP都可以访问，并不是指定IP。

看下防火墙设置：

iptables-save
# 输出了两部分
# 第一部分，nat表，部分内容如下
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [4:296]
:POSTROUTING ACCEPT [4:296]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.28.0.0/16 ! -o br-0be676646756 -j MASQUERADE
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 3306 -j MASQUERADE
-A DOCKER -i br-0be676646756 -j RETURN
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 3307 -j DNAT --to-destination 172.17.0.2:3306
COMMIT

这里可以看到在nat表的DOCKER链中，对目的IP进行了nat转换，变成了容器IP: 3307

那么，正确是设置规则对内部端口进行设置

# 设置容器内部端口
iptables -I DOCKER-USER -p tcp –s 10.0.0.1 –dport 3306 -j ACCEPT

如果是有两个容器，内部端口都是3306，此时可以对容器IP进行控制：

# 容器一的IP：172.0.0.1
iptables -I DOCKER-USER -p tcp –s 10.0.0.1 –d 172.0.0.1 –dport 3306 -j ACCEPT# 容器二的IP：172.0.0.2
iptables -I DOCKER-USER -p tcp –s 10.0.0.2 –d 172.0.0.2 –dport 3306 -j ACCEPT