回顾一下业务中的网络技术演化
这个版本解决了一个几年前遗留的网络问题，近期可能不会再对网络相关的模块进行迭代了，这里回顾一下这些年网络相关技术在业务中的迭代。
背景
业务的枢纽为 感知攻击者入侵的欺骗服务 ，处于枢纽之后核心功能为 服务管理 及 入侵行为分析 ，处于枢纽之前的核心功能为 引流。
引流的目的为扩大感知面，增加攻击者入侵感知的几率，这部分功能和网络关联比较多，所以这里聚焦网络相关基础功能和随业务迭代变更。
- 引流模块基础模块
- [宿主机虚拟 IP 引流](#宿主机虚拟 IP 引流)
- 服务器部署代理节点引流
- 交换机侧虚拟网络引流
- 业务迭代变更
- [内部化 VM IP](#内部化 VM IP)
- 业务架构调整
引流模块基础模块
三种引流模块是从宿主机一层层往外扩展的叠加，是产品网络相关的基础形态。
宿主机虚拟 IP 引流
在宿主机上配置多个虚拟 IP，并通过 iptables DNAT 规则将访问这些IP的流量透明转发至欺骗服务。
背景
服务位于虚拟机中（安全性考虑），监听特定端口，虚拟机使用桥接方式连接到宿主机。带来的限制：欺骗服务只能通过虚拟机的 IP 地址访问，链路只有一条。
考虑如何在宿主机内增加访问这个欺骗服务的链路
- 增加 IP 并且将这个 IP 的流量重定向到欺骗服务所在虚拟机中
- 增加流量代理，将流量代理至欺骗服务的端口上
业务采取的是第一种方式，增加虚拟IP 并且使用 iptables 将流量 DNAT 至虚拟机上，这样可以保持服务感知的源地址不变。
实现
增加的虚拟 IP 有几种方式，早期业务使用第二种方式
- 直接在物理网卡上增加 IP
- 使用 macvlan 虚拟网卡，然后再虚拟网上添加 IP
- 使用 netns 隔离 IP，每个 IP 独占一个命名空间以及 MAC 地址
选择第二种方案是：第一种方案过于简陋，第三种方案未采用是由于当时对网络命名空间不熟悉。
创建网卡，添加 IP
shell
$ ip link add link br0 name macvlan0 type macvlan
$ ip link set macvlan0 up
$ ip addr add 192.168.32.247/24 dev macvlan0
$ ip addr show macvlan0增加 iptables DNAT 规则，将访问 192.168.32.247 的流量重定向至 192.168.32.245 上（虚拟机 IP）
shell
$ iptables -t nat -A PREROUTING -d 192.168.32.247/32 -j DNAT --to-destination 192.168.32.245前置条件
shell
$ iptables -P FORWARD ACCEPT
$ sysctl -w net.ipv4.ip_forward=1在 iptables 的加持下，虚拟网卡只用于内核回复 ARP Request，后续的 TCP 通信流量不会经过这个网卡。
简单的网络拓扑如下，虚拟机使用桥接模式，在 DNAT 规则增加后，通过 192.168.32.247 也可以访问到虚拟机。
txt
┌───────────────────────────────────────────┐
│ Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 192.168.32.245 │ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ ┌──> vnet1 │
│ │ │ │
│ │ │ 192.168.32.247 │
│ DNAT │ │ ─── macvlan0 │
│ │ │ │
│ │ │ │
│ └──── br0 192.168.32.251 │
└──────────────────│────────────────────────┘
eth0服务器部署代理节点引流
通过部署代理节点 agent，监听指定IP地址及端口，并将接收到的流量代理至欺骗服务。
背景
目前在宿主机环境只能增加同网段的IP，那不同子网的 IP 如何引流？答：加一个流量代理。
代理的 agent 部署在客户业务机器内，管理端将需要代理的规则下发至 agent，agent 监听端口并且将流量代理至欺骗服务。
这样存在一个问题：欺骗服务需要获取真实的的对端地址，简单的代理会丢失这个信息，拿到的对端地址是 agent 的本地地址。
对于 Service 而言，conn.RemoteAddr() 得到的结果是正确的，这是直连的结果。
txt
conn
User <-------> Service
ip1 ip3pconn.RemoteAddr() 得到的结果是代理 agent 地址，不符合期望
txt
uconn pconn
User <-------> Proxy <-------> Service
ip1 ip2 ip3如何解决这个问题：宿主机增加一个网关服务，代理 agent 携带 uconn.RemoteAddr() 等相关元数据发送至网关服务，
网关服务收到元数据后增加 SNAT 规则并且将流量代理至欺骗服务，这样欺骗服务感知到的对端地址是真实的。
实现
使用自定义协议，在每个连接的头部增加
- 8 字节魔数，用于区分内部连接
- 对端地址
- 需要转发的目的地址（欺骗服务）
增加 SNAT 的关键 一步：建立 TCP 连接前，需要指定源地址，源 IP 取 HostIP（192.168.32.251），端口通过 net.Listen("tcp", "0.0.0.0:0") 提前分配，这样连接的五元组就固定下来，后面规则就是机械的参数填充了。
shell
$ iptables -t nat -A POSTROUTING -s 192.168.32.251/32 -p tcp -m tcp --sport 34162 -j SNAT --to-source 192.168.1.55:46421简单的网络拓扑如下，增加了 gateway 服务，接收来自 代理 agent 的流量，在代理连接建立之前增加 SNAT 规则。
txt
┌─────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 192.168.32.245 │ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ ┌──────────> vnet1 │
│ │ │ │ │
│ │ │ │ 192.168.32.247 │
│ SNAT│ DNAT│ │ ─── macvlan0 │
│ │ │ │ │
│ │ │ │ │
│ Gateway └──── br0 192.168.32.251 │
└────────────────────────│────────────────────────┘
eth0 交换机侧虚拟网络引流
在核心交换机侧部署虚拟网络节点，创建虚拟 VLAN/VXLAN IP 并监听指定IP地址及端口，将流量代理至欺骗服务。
背景
继续扩大感知面，在代理节点 agent 的基础上，同网段、不同网段已经能够覆盖。
但是都是针对已存在的网段进行引流，这部分在整个网络中的比例是比较低的，如果可以覆盖到这些不存在的网络，那么可以极大增加感知面。
如何虚拟不存在的网络，这里涉及到交换机的一些原理（暂时不考虑 vxlan）：
- （二层）交换机通过 VLAN 创建一个独立的广播域
- （三层）交换机为 VLAN 创建一个虚拟接口，并且为这个接口分配网关和掩码（192.168.1.1/24）
- （三层）交换机包的路由查询，将数据包从目标网段对应的 VLAN 接口发送出去
- ACCESS 接口，包出去的时候剥离 VLAN tag， 包进入则打上 VLAN tag
- TRUNK 接口，可以收到所有的网络数据包
内核支持 vlan 虚拟网卡，可以使用内核对 vlan tag 解析封装和解封装。
实现
利用的交换机的特性，提前做一些操作
- 分配 vlan 和对应的网段
- 分配 trunk 口，这样该 trunk 口接入的服务器相当于核心交换机下的接入交换机
在接入的服务器内部署代理 agent 的基础上，只需要额外做一件事情：管理 vlan 网卡和 ip
早期没有接触过 netns ，这些操作都是在 host 内完成的，这里不讨论过时的设计了。
遇到的一些问题和解决方案
- 一个 agent 需同时接入交换机的 trunk 口，使用了 netns 隔离网络来解决，一个网段（一个 VLAN 可能存在多个网段）占用一个 netns。
- 虚拟过万数量的 IP，按照之前 agent 的监听逻辑，一个 IP:Port 的监听就会占用一个 fd，使用 iptables+ipset DNAT 解决
- IP:Port 存入 hash:ip,port 的 ipset 中
- 使用一条 iptables 规则，匹配 ipset 将流量 DNAT 到一个监听地址上
- 使用 netns 隔离 iptables 规则和监听地址，整体 fd 占用数量较少
整体方案如下：
- 创建网桥，并且将物理网卡挂载在网桥上
- 设置通信网卡及 IP，用于流量代理和规则获取，也挂在网桥上
- 创建虚拟网络
- 创建 netns
- 创建 veth-peer，宿主空间挂载在网桥上，up 所有网卡
- 在 netns 内部的 veth-peer 上创建虚拟 vlan 网卡，并且增加 ip
- 在 netns 内创建 ipset，增加 iptables 规则
- agent 切换命名空间，在 netns 内部监听端口（这样一个进程可以监听多个命名空间内的地址）
shell
# 创建网桥
$ ip link add br1 type bridge
$ ip link set br1 up
$ ip lihk set eth0 master br1
# 创建通信网卡，保持存在一个基础的 IP 和外界通信
$ ip link add link br1 name veth0 type vlan id 100
$ ip link set veth0 up
$ ip addr add 192.168.100.100/24 dev veth0
# 创建虚拟网络
$ ip netns add ns1
$ ip link add veth1 type veth peer name eth0 netns ns1
$ ip netns exec ns1 ip link set eth0 up
$ ip netns exec ns1 ip link set lo up
$ ip link set veth1 up
$ ip link set veth1 master br1
# 设置虚拟 VLAN(100) 网卡和添加 IP
$ ip netns exec ns1 ip link add link eth0 name vlan100 type vlan id 100
$ ip netns exec ns1 ip link set vlan100 up
$ ip netns exec ns1 ip addr add 192.168.110.2/24 dev vlan100
$ ip netns exec ns1 ip route add default via 192.168.110.1 onlink dev vlan100
# 新增 iptables/ipset 规则
$ ip netns exec ns1 ipset create ipset1 hash:ip,port
$ ip netns exec ns1 iptables -t nat -A PREROUTING -p tcp -m set --match-set ipset1 dst,dst -j DNAT --to-destination 127.0.0.1:5550遇到的一些问题
- DNAT 127.0.0.1 需要开启
net.ipv4.conf.all.route_localnet=1 - ipset 在 3.10 的内核上兼容性不好，没有区分宿主机和命名空间，只能通过命名进行区分解决
网络侧的代理网络拓扑如下
txt
┌───────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ ns1 │ │ ns2 │ │
│ │ │ │ │ │
│ │ 192.168.100.2 │ │ 192.168.101.8 │ │
│ │ vlan100 │ │ vlan101 │ │
│ │ │ │ │ │ │ │
│ │ eth0 │ │ eth0 │ │
│ 192.168.100.100 └────────│────────┘ └────────│────────┘ │
│ veth0 veth1 veth2 │
│ │ │ │ │
│ └───────────────────│─────────────────────┘ │
│ │ │
│ br0 │
└────────────────────────────│──────────────────────────────────┘
eth0 如果是多张网卡，那么保持基础通信的 IP，新增一个网桥连接虚拟网络和物理网卡即可，这样 ns1 和 ns2 就独立不受影响了
txt
┌───────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ ns1 │ │ ns2 │ │
│ │ │ │ │ │
│ │ 192.168.100.2 │ │ 192.168.101.8 │ │
│ │ vlan100 │ │ vlan101 │ │
│ │ │ │ │ │ │ │
│ │ eth0 │ │ eth0 │ │
│ 192.168.100.100 └────────│────────┘ └────────│────────┘ │
│ veth0 veth1 veth2 │
│ │ │ │ │
│ └───────────────────│ │ │
│ │ │ │
│ br1 br2 │
└────────────────────────────│─────────────────────│────────────┘
eth0 eth1 vxlan 支持
同样需要交换机进行配置，另外使用 bgp 协议来动态控制路由，frr 提供这些功能，设置好 AS 号即可。
其他和网络相关的逻辑参考 几种通过 iproute2 来打通不同节点间容器网络的方式，关于 vxlan 如何跨节点通信，网络配置几乎相同。
完整的网络拓扑如下，vxlan 的命名空间对应一个网段，一个 vni 对应一个网桥，通过网桥连接命名空间和 vtep 设备。
txt
┌─────────────────────────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ ns1 │ │ ns2 │ │ ns3 │ │
│ │ │ │ │ │ │ │
│ │ 192.168.100.2 │ │ 192.168.101.8 │ │ │ │
│ │ vlan100 │ │ vlan101 │ │ │ │
│ │ │ │ │ │ │ │ 10.1.0.10 │ │
│ │ eth0 │ │ eth0 │ │ eth0 │ │
│ 192.168.100.100 └────────│────────┘ └────────│────────┘ └────────│────────┘ │
│ veth0 veth1 veth2 veth3 │
│ │ │ │ │ │
│ └──────────────────│ │ │── vtep1 │
│ │ │ │ │
│ br1 br2 br3 │
└───────────────────────────│────────────────────│────────────────────────────────┘
eth0 eth1 eth2
└────────────────────│────────────────────┘
switch 业务迭代变更
这部分是属于欺骗服务宿主机内部的变更逻辑，和前面几个技术点比起来没有那么纯粹，夹杂着业务逻辑。
这部分忽略前面三个引流部分，目前的网络拓扑为
txt
┌───────────────────────────────────────────┐
│ Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 192.168.32.245 │ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ vnet1 │
│ │ │
│ br0 192.168.32.251 │
└──────────────────│────────────────────────┘
eth0内部化 VM IP
网络环境出现重复 IP 的情况下，对 vm 存活的判断可能出现错误而回收 vm。
将 vm 内部化来避免这个问题，如果 IP 访问失败也不会影响 vm 的状态，新增一个 br1 复用之前的多 IP DNAT 逻辑即可。
txt
┌───────────────────────────────────────────┐
│ Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 172.16.23.2 │ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ ┌── vnet1 │
│ │ │ │
│ DNAT│ br1 172.16.23.1 │
│ │ │
│ └─── br0 192.168.32.251 │
└──────────────────│────────────────────────┘
eth0业务架构调整
现在由于性能和后面维护考虑，决定将 vm 中的欺骗服务移动至 docker 容器内
- 出于安全性考虑，保留 vm（docker 相对 vm 更容易逃逸）
- 性能更优，容器的占用远低于 vm，这样可以启动更多的欺骗服务
- 可维护性更强，服务的部署逻辑都在 dockefile 中被持久化
- windows 类型的 vm 保持不变
调整后的网络拓扑为一个异构网络架构，如下
txt
┌───────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────────────┐ ┌─────────────┐ │
│ │ vm1 │ │ vm2(win) │ │
│ │ ┌────────┐ ┌────────┐ │ │ │ │
│ │ │10.1.0.2│ │10.1.0.3│ │ │ │ │
│ │ │ eth0 │ │ eth0 │ │ │ │ │
│ │ └───│────┘ └───│────┘ │ │ │ │
│ │ veth1 veth2 │ │ │ │
│ │ └──────│─────┘ │ │ │ │
│ │ docker0 │ │ │ │
│ │ 10.1.0.1 │ │ │ │
│ │ │ │ │ │
│ │ 172.16.23.2 │ │ 172.16.23.3 │ │
│ │ eth0 │ │ eth0 │ │
│ └────────────│────────────┘ └──────│──────┘ │
│ vnet1 vnet2 │
│ └───────────────│─────────┘ │
│ 192.168.32.251 br1 │
│ br0 172.16.23.1 │
└────────│──────────────────────────────────────────────────────┘
eth0 如何访问新架构的欺骗服务
之前访问欺骗服务的方式
- 直接访问 IP，流量 DNAT 至 vm
- 访问代理监听的端口，通过 gateway 转发至欺骗服务
如果把 gateway 的转发功能部署在 vm 里面，host 把所有的流量转发至 vm 内，那么可以复用之前 SNAT 规则。
如何将 host 内的流量转发至 vm？
- 在交换机侧虚拟网络引流逻辑上，在命名空间内部有一条 iptables 规则把流量 DNAT 到一个端口上，对于 IP 的访问复用这个逻辑
- 代理流量的访问，增加一个代理即可，对于欺骗服务而言都是透明的
调整后的流量链路如下:
txt
┌───────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────────────┐ ┌─────────────┐ │
│ │ vm1 │ │ vm2(win) │ │
│ │ ┌────────┐ ┌────────┐ │ │ │ │
│ │ │ srv1 │ │ srv2 │ │ │ srv3 │ │
│ │ │10.1.0.2│ │10.1.0.3│ │ │ │ │
│ │ └───│────┘ └───│────┘ │ │ 172.16.23.3 │ │
│ │ └──────│─────┘ │ └──────│──────┘ │
│ │ SNAT │ SNAT │
│ │ │ │ │ │
│ │ gateway2 (Listen) │ gateway2 (Listen) │
│ │ │ 172.16.23.2│ │ 192.168.32.251│
│ └────────────│────────────┘ │ │
│ └───────────────│─────────┘ │
│ L4 Proxy │
│ │ │
│ 192.168.32.100 gateway1 (Listen) │
│ 192.168.32.101 │ 192.168.32.251 │
│ br0 ───────── DNAT ───────────┘ │
│ │ │ │
│ │ ──────── L4 Proxy ─────────┘ │
└────────│──────────────────────────────────────────────────────┘
eth0 调整后的 gateway1 成为了整个所有服务的流量入口，后面可以根据这个特性对架构进行调整。
异构问题如何解决
在新架构的访问链路中，两类欺骗服务明显的异构，监听的 IP 不在一个层级，一类是 10.* 一类是 172.*。
目前 gateway2 需要处理两套转发逻辑，除了丑一些功能是没有问题的。
现在有一个需求需要打通欺骗服务的网络链路，srv1/srv2/srv3 可以互相访问对方的服务端口。
同构网络架构方案
对于同网络架构的网络打通方案见 几种通过 iproute2 来打通不同节点间容器网络的方式。
异构网络架构方案
比较容易想到的方案是，少了一层那么为了兼容增加一层处理逻辑即可。
有了 交换机侧虚拟网络引流 的经验，netns 可以在这个地方尝试使用。
理论上以下的网络拓扑是可以正常运行的，但是存在一个问题：网桥 br-win 在 netns 里面，kvm 不能指定这个网桥。
txt
┌─────────────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────────────┐ ┌─────────────────────────┐ │
│ │ vm1 │ │ netns_win │ │
│ │ ┌────────┐ ┌────────┐ │ │ ┌────────┐ ┌────────┐ │ │
│ │ │10.1.0.2│ │10.1.0.3│ │ │ │10.2.0.2│ │10.2.0.3│ │ │
│ │ │ eth0 │ │ eth0 │ │ │ │ eth0 │ │ eth0 │ │ │
│ │ └───│────┘ └───│────┘ │ │ └───│────┘ └───│────┘ │ │
│ │ veth1 veth2 │ │ vnet2 vnet3 │ │
│ │ └──────│─────┘ │ │ └──────│─────┘ │ │
│ │ docker0 │ │ br-win │ │
│ │ 10.1.0.1 │ │ 10.2.0.1 │ │
│ │ │ │ │ │
│ │ 172.16.23.2 │ │ 172.16.23.3 │ │
│ │ eth0 │ │ eth0 │ │
│ └────────────│────────────┘ └────────────│────────────┘ │
│ vnet1 veth-win │
│ └───────────────│───────────────┘ │
│ 192.168.32.251 br1 │
│ br0 172.16.23.1 │
└────────│────────────────────────────────────────────────────────────┘
eth0 所以需要调整一下，把 br-win 放在 host 内，使用 veth-peer 把 ip 留在命名空间内，变更后的网络拓扑如下：
txt
┌─────────────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────────────┐ │
│ │ vm1 │ │
│ │ ┌────────┐ ┌────────┐ │ ┌────────┐ ┌────────┐ │
│ │ │10.1.0.2│ │10.1.0.3│ │ │10.2.0.2│ │10.2.0.3│ │
│ │ │ eth0 │ │ eth0 │ │ │ eth0 │ │ eth0 │ │
│ │ └───│────┘ └───│────┘ │ └───│────┘ └───│────┘ │
│ │ veth1 veth2 │ vnet2 vnet3 │
│ │ └──────│─────┘ │ └──────│─────┘ │
│ │ docker0 │ br-win │
│ │ 10.1.0.1 │ │ │
│ │ │ veth-win1 │
│ │ │ ┌────────────│────────────┐ │
│ │ │ │ netns eth1 │ │
│ │ │ │ win 10.2.0.1 │ │
│ │ │ │ │ │
│ │ 172.16.23.2 │ │ 172.16.23.3 │ │
│ │ eth0 │ │ eth0 │ │
│ └────────────│────────────┘ └────────────│────────────┘ │
│ vnet1 veth-win0 │
│ └───────────────│───────────────┘ │
│ 192.168.32.251 br1 │
│ br0 172.16.23.1 │
└────────│────────────────────────────────────────────────────────────┘
eth0 如何对恶意流量进行分析
业务中使用 suricata 对流量进行分析，部署在欺骗服务所在的网桥上，这个位置获取拿到原始的流量数据。
如果是在 br0 的位置抓包，拿到的流量会携带一个 L4 Proxy 的源数据头，这个数据头会导致 suricata 识别不了一些协议，如何 HTTP。
txt
┌────────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────────────┐ │
│ │ vm1 │ │
│ │ ┌────────┐ ┌────────┐ │ ┌────────┐ │
│ │ │ srv1 │ │ srv2 │ │ │10.2.0.2│ │
│ │ │10.1.0.2│ │10.1.0.3│ │ │ eth0 │ │
│ │ └───│────┘ └───│────┘ │ └───│────┘ │
│ │ └──────│─────┘ │ │ │
│ │ suricata ──│ │ suuricata ──│ │
│ │ SNAT │ SNAT │
│ │ │ │ ┌───────────│───────────┐ │
│ │ │ │ │ │ │ │
│ │ gateway2 (Listen) │ │ gateway2 (Listen)│ │
│ │ │ 172.16.23.2│ │ │172.16.23.3│ │
│ └────────────│────────────┘ └───────────│───────────┘ │
│ └───────────────│──────────────┘ │
│ L4 Proxy │
│ │ │
│ 192.168.32.100 gateway1 (Listen) │
│ 192.168.32.101 │ 192.168.32.251 │
│ br0 ───────── DNAT ───────────┘ │
│ │ │ │
│ │ ──────── L4 Proxy ─────────┘ │
└────│───────────────────────────────────────────────────────────┘
eth0 suricata 在没有流量的情况下也就是有一定的资源占用的，整个 Host 机器可能存在多个 vm，意味着也存在多个 suricata。
目标：减少 suricata 数量，复用 suricata 资源，降低服务管理的成本。
gateway1 是所有流量的入口，只要拿到 gateway1 和 gateway2 之间的流量，并且去掉头部就是原始流量了。
比较占用性能的方案如下：
- 抓包 br1 网桥，获取所有的网桥流量
- 新建虚拟 tap 设备，指定网卡为 tap 设备启动 suricata
- 建立连接，增加连接相关的缓存
- 对包进行匹配和重组
- 匹配流量头
- 去掉流量头，修改 seq/ack 序号，重新生成一个网络数据包
- 新的数据包写入至 tap 设备中
- 接收 suricata 的事件，使用缓存相关的数据订正 IP 相关信息
调整后的的网络拓扑如下，新增 vtap0 给 suricata 抓包分析恶意流量
txt
┌─────────────────────────────────────────────────────────────────────┐
│ Host │
│ ┌─────────────────────────┐ │
│ │ vm1 │ │
│ │ ┌────────┐ ┌────────┐ │ ┌────────┐ ┌────────┐ │
│ │ │10.1.0.2│ │10.1.0.3│ │ │10.2.0.2│ │10.2.0.3│ │
│ │ │ eth0 │ │ eth0 │ │ │ eth0 │ │ eth0 │ │
│ │ └───│────┘ └───│────┘ │ └───│────┘ └───│────┘ │
│ │ veth1 veth2 │ vnet2 vnet3 │
│ │ └──────│─────┘ │ └──────│─────┘ │
│ │ docker0 │ br-win │
│ │ 10.1.0.1 │ │ │
│ │ │ veth-win1 │
│ │ │ ┌────────────│────────────┐ │
│ │ │ │ netns eth1 │ │
│ │ │ │ win 10.2.0.1 │ │
│ │ │ │ │ │
│ │ 172.16.23.2 │ │ 172.16.23.3 │ │
│ │ eth0 │ │ eth0 │ │
│ └────────────│────────────┘ └────────────│────────────┘ │
│ vnet1 veth-win0 │
│ └───────────────│───────────────┘ │
│ 192.168.32.251 br1 ─────────────┐ │
│ br0 172.16.23.1 vtap0 │
└────────│────────────────────────────────────────────────────────────┘
eth0 一些想法
- netns 是个好东西，对于网络的隔离可以做到非常灵活的程度
- 涉及对外自定义的协议尽量使用常见协议，否则外部一旦部署升级也会麻烦一些，涉及三方服务也不能识别，比如 suricata 如果是用 HA Proxy 是可以支持剥离的
参考
- 几种通过 iproute2 来打通不同节点间容器网络的方式，https://www.cnblogs.com/shuqin/p/18529071