[解决方案] 回顾一下业务中的网络技术演化
回顾一下业务中的网络技术演化这个版本解决了一个几年前遗留的网络问题，近期可能不会再对网络相关的模块进行迭代了，这里回顾一下这些年网络相关技术在业务中的迭代。
背景
业务的枢纽为 感知攻击者入侵的欺骗服务，处于枢纽之后核心功能为 服务管理 及 入侵行为分析，处于枢纽之前的核心功能为 引流。
引流的目的为扩大感知面，增加攻击者入侵感知的几率，这部分功能和网络关联比较多，所以这里聚焦网络相关基础功能和随业务迭代变更。
[*]引流模块基础模块
[*]宿主机虚拟 IP 引流
[*]服务器部署代理节点引流
[*]交换机侧虚拟网络引流
[*]业务迭代变更
[*]内部化 VM IP
[*]业务架构调整
[*]如何访问新架构的欺骗服务
[*]异构问题如何解决
[*]如何对恶意流量进行分析
引流模块基础模块
三种引流模块是从宿主机一层层往外扩展的叠加，是产品网络相关的基础形态。
宿主机虚拟 IP 引流
在宿主机上配置多个虚拟 IP，并通过 iptables DNAT 规则将访问这些IP的流量透明转发至欺骗服务。
背景
服务位于虚拟机中（安全性考虑），监听特定端口，虚拟机使用桥接方式连接到宿主机。带来的限制：欺骗服务只能通过虚拟机的 IP 地址访问，链路只有一条。
考虑如何在宿主机内增加访问这个欺骗服务的链路
[*]增加 IP 并且将这个 IP 的流量重定向到欺骗服务所在虚拟机中
[*]增加流量代理，将流量代理至欺骗服务的端口上
业务采取的是第一种方式，增加虚拟IP并且使用 iptables 将流量 DNAT 至虚拟机上，这样可以保持服务感知的源地址不变。
实现
增加的虚拟 IP 有几种方式，早期业务使用第二种方式
[*]直接在物理网卡上增加 IP
[*]使用 macvlan 虚拟网卡，然后再虚拟网上添加 IP
[*]使用 netns 隔离 IP，每个 IP 独占一个命名空间以及 MAC 地址
选择第二种方案是：第一种方案过于简陋，第三种方案未采用是由于当时对网络命名空间不熟悉。
创建网卡，添加 IP
$ 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）
$ iptables -t nat -A PREROUTING -d 192.168.32.247/32 -j DNAT --to-destination 192.168.32.245前置条件
$ iptables -P FORWARD ACCEPT
$ sysctl -w net.ipv4.ip_forward=1在 iptables 的加持下，虚拟网卡只用于内核回复 ARP Request，后续的 TCP 通信流量不会经过这个网卡。
简单的网络拓扑如下，虚拟机使用桥接模式，在 DNAT 规则增加后，通过 192.168.32.247 也可以访问到虚拟机。
┌───────────────────────────────────────────┐
│Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 192.168.32.245│ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ ┌──> vnet1 │
│ │ │ │
│ │ │ 192.168.32.247 │
│ DNAT │ │ ─── macvlan0 │
│ │ │ │
│ │ │ │
│ └──── br0192.168.32.251 │
└──────────────────│────────────────────────┘
eth0服务器部署代理节点引流
通过部署代理节点 agent，监听指定IP地址及端口，并将接收到的流量代理至欺骗服务。
背景
目前在宿主机环境只能增加同网段的IP，那不同子网的 IP 如何引流？答：加一个流量代理。
代理的 agent 部署在客户业务机器内，管理端将需要代理的规则下发至 agent，agent 监听端口并且将流量代理至欺骗服务。
这样存在一个问题：欺骗服务需要获取真实的的对端地址，简单的代理会丢失这个信息，拿到的对端地址是 agent 的本地地址。
对于 Service 而言，conn.RemoteAddr() 得到的结果是正确的，这是直连的结果。
conn
User <-------> Service
ip1 ip3pconn.RemoteAddr() 得到的结果是代理 agent 地址，不符合期望
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") 提前分配，这样连接的五元组就固定下来，后面规则就是机械的参数填充了。
$ 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 规则。
┌─────────────────────────────────────────────────┐
│Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 192.168.32.245│ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ ┌──────────> vnet1 │
│ │ │ │ │
│ │ │ │ 192.168.32.247 │
│ SNAT│ DNAT│ │ ─── macvlan0 │
│ │ │ │ │
│ │ │ │ │
│ Gateway └──── br0192.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 内部监听端口（这样一个进程可以监听多个命名空间内的地址）
# 创建网桥
$ 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 的内核上兼容性不好，没有区分宿主机和命名空间，只能通过命名进行区分解决
网络侧的代理网络拓扑如下
┌───────────────────────────────────────────────────────────────┐
│ 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 就独立不受影响了
┌───────────────────────────────────────────────────────────────┐
│ 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 设备。
┌─────────────────────────────────────────────────────────────────────────────────┐
│ 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 业务迭代变更
这部分是属于欺骗服务宿主机内部的变更逻辑，和前面几个技术点比起来没有那么纯粹，夹杂着业务逻辑。
这部分忽略前面三个引流部分，目前的网络拓扑为
┌───────────────────────────────────────────┐
│Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 192.168.32.245│ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ vnet1 │
│ │ │
│ br0192.168.32.251 │
└──────────────────│────────────────────────┘
eth0内部化 VM IP
网络环境出现重复 IP 的情况下，对 vm 存活的判断可能出现错误而回收 vm。
将 vm 内部化来避免这个问题，如果 IP 访问失败也不会影响 vm 的状态，新增一个 br1 复用之前的多 IP DNAT 逻辑即可。
┌───────────────────────────────────────────┐
│Host │
│ ┌─────────────────┐ │
│ │ vm1 │ │
│ │ 172.16.23.2 │ │
│ │ eth0 │ │
│ └────────│────────┘ │
│ ┌── vnet1 │
│ │ │ │
│ DNAT│ br1172.16.23.1 │
│ │ │
│ └─── br0192.168.32.251 │
└──────────────────│────────────────────────┘
eth0业务架构调整
现在由于性能和后面维护考虑，决定将 vm 中的欺骗服务移动至 docker 容器内
[*]出于安全性考虑，保留 vm（docker 相对 vm 更容易逃逸）
[*]性能更优，容器的占用远低于 vm，这样可以启动更多的欺骗服务
[*]可维护性更强，服务的部署逻辑都在 dockefile 中被持久化
[*]windows 类型的 vm 保持不变
调整后的网络拓扑为一个异构网络架构，如下
┌───────────────────────────────────────────────────────────────┐
│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 的访问复用这个逻辑
[*]代理流量的访问，增加一个代理即可，对于欺骗服务而言都是透明的
调整后的流量链路如下:
┌───────────────────────────────────────────────────────────────┐
│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 不能指定这个网桥。
┌─────────────────────────────────────────────────────────────────────┐
│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 留在命名空间内，变更后的网络拓扑如下：
┌─────────────────────────────────────────────────────────────────────┐
│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。
┌────────────────────────────────────────────────────────────────┐
│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 抓包分析恶意流量
┌─────────────────────────────────────────────────────────────────────┐
│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
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]