- bridge
- 默认网络，Docker启动后创建一个docker0网桥，默认创建的容器也是添加到这个网桥中。
- host
- 容器不会获得一个独立的network namespace，而是与宿主机共用一个。这就意味着容器不会有自己的网卡信息，而是使用宿主机的。容器除了网络，其他都是隔离的。
- none
- 获取独立的network namespace，但不为容器进行任何网络配置，需要我们手动配置。
- container
- 与指定的容器使用同一个network namespace，具有同样的网络配置信息，两个容器除了网络，其他都还是隔离的。
- 自定义网络
- 与默认的bridge原理一样，但自定义网络具备内部DNS发现，可以通过容器名容器之间网络通信。
默认都为bridge网卡
容器内为什么能通baidu
容器内虚拟网卡网卡——》容器网关（宿主机虚拟网卡）——》docker0网卡——》物理网卡
我做了一个实验，发现两种情况
第一种情况，容器会走vet网卡在到docker0网卡，所以在两张网卡上都能抓到对应的数据包。
第二种情况，在docker0网卡上抓不到流量，只能在对应的veth网卡上才能抓到流量
我发现docker0上并不能抓到容器的流量
在使用traceroute查看路由后，我发现，容器在出网关后到了192.168.68.2，该ip为物理机物理网卡网关，意思是，该容器，从容器虚拟网关出来后直接到了物理机网关，跳过了docker0网卡，所以使用tcpdump -i docker0抓取该容器流量是抓不到的
为什么会出现这总问题，在查看iptables规则时，我发现，在docker创建时可能会添加一些规则
iptables -t nat -S
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
这条规则的意思是如果docker0收到来自172.17.0.0/16这个网段的外出包，docker0会交给MASQUERADE处理，而MASQUERADE处理方式是将包源地址替换成host地址发出
所以，跳过docker0网卡直接到物理网卡的原因是iptables规则中有该网卡直接nat出去的规则
观察其状态，映射端口
docker container ls
docker ps
检查容器详细信息，挂载的数据卷，运行时间，mac地址等信息
docker inspect ID
检查容器资源使用情况
docker stats ID
容器进程信息
docker top ID
容器文件信息
docker diff ID | grep A
# A -add
# D -delete
# C -change
- 构建镜像，保留证据
- 检查异常
- 暂停容器内进程
- 断开容器网络
构建镜像
docker commit -m="说明" ID check08:1.0
暂停容器中的进程，包括后台，守护进程等，文件系统运行状态不变
docker pause ID # 暂停
docker unpause ID # 恢复
容器通过docker0网卡进行通信，可以通过tcpdump指定网卡找到异常网络连接，然后进一步关联容器。
情况一：ids或其他安全设备告警，某台linux上出现了恶意连接，该linux主机上部署了多个容器，该如何排查是那个容器出现了问题？
在宿主机上通过netstat -an 是看不到容器内的网络连接的，而一台台进入容器查看网络连接，排查效率很慢，而且很多容器没有安装net-tools工具，没有netstat工具。
情况一：直接通过docker0网卡进行tcpdump流量抓取，通过安全设备给出的IP地址定位容器。
情况二：docker0网卡无法抓取到，只能一个一个网卡进行排查。
抓取docker0网卡流量
tcpdump -i docker0 dst host xx.xx.xx.xx -v -w docker.pcap
抓取容器对应的veth流量
iptables -t nat -S # 查看对应网卡
tcpdump -i br-28b6e6930d36 dst host 172.29.246.156 -v -w br-28b6e6930d36.pcap
tcpdump -i br-28b6e6930d36 dst host 172.29.246.156 -v
利用docker inspect -f匹配模块文件匹配对应容器
docker inspect -f '{{.Name}}{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq) | grep 172.19.0.2
docker container ls -a | grep 82-pte-lamp-1
