《零入门kubernetes网络实战》视频专栏地址
https://www.ixigua.com/7193641905282875942
本篇文章视频地址(稍后上传)
本篇文章主要测试使用vxlan的点对点模式下实现跨主机的内网通信。
本篇文章采用的vxlan点对点模式是静态点对点，也就是说，目的VETP设备已经确定好了，目的VETP设备的MAC信息是确定的。
不需要通过其他方式获取。
主要用到的网络设备包括：veth pair, bridge ,vxlan；
以及路由技术，UDP协议。
| 1、总结 |
- 本篇文章主要是测试了静态点对点模式下的vxlan技术，如何实现"不同节点上的内网如何实现跨节点通信"。
- 重点分析了第一次请求时，数据包的报文结构变化过程
- 重点分析了第一次请求时，数据包主要经过了哪些iptables规则链
- 重点分析了第一次请求时，数据包从发送端到接收端整个过程，都涉及到了哪些网络设备，路由，网络协议等
- 阐释了为什么说vxlan模式是MAC in UDP?
- wireshark如何解析UDP数据包？
| 2、测试环境介绍 |
两台centos虚拟机
# 查看操作系统版本
cat /etc/centos-release
# 内核版本
uname -a
uname -r
# 查看网卡信息
ip a s eth0
| 3、网络拓扑 |
| 4、操作实战 |
| 4.1、master节点上 |
接下来，在master节点上，通过相关命令来构建网络拓扑
| 4.1.1、创建ns1网络命名空间 |
ip netns add ns1
| 4.1.2、创建网桥、并设置IP |
ip link add br0 type bridge
ip addr add 10.244.1.1/24 dev br0
ip link set br0 up
| 4.1.3、创建veth pair，并进行相应设置 |
ip link add veth1a type veth peer name veth1b
ip link set veth1a netns ns1
ip netns exec ns1 ip address add 10.244.1.2/24 dev veth1a
ip netns exec ns1 ip link set veth1a up
ip link set veth1b master br0
ip link set veth1b up
ip netns exec ns1 ip link set lo up
| 4.1.4、创建vxlan设备，并进行相应设置 |
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.123 local 10.211.55.122 dev eth0
ip addr add 10.244.1.0/32 dev vxlan11
ip link set vxlan11 up
| 4.1.5、进入到ns1空间里，设置去往其他网段的路由 |
ip netns exec ns1 ip route add 10.244.2.0/24 via 10.244.1.1 dev veth1a
| 4.1.6、在主命名空间下，设置去往其他VTEP设备的路由 |
ip r a 10.244.2.0/24 via 10.244.2.0 dev vxlan11 onlink
| 4.2、slave节点上 |
接下来，在slave节点上，通过相关命令来构建网络拓扑
| 4.2.1、创建ns2网络命名空间 |
ip netns add ns2
| 4.2.2、创建网桥、并设置IP |
ip link add br0 type bridge
ip addr add 10.244.2.1/24 dev br0
ip link set br0 up
| 4.2.3、创建veth pair，并进行相应设置 |
ip link add veth2a type veth peer name veth2b
ip link set veth2a netns ns2
ip netns exec ns2 ip address add 10.244.2.2/24 dev veth2a
ip netns exec ns2 ip link set veth2a up
ip link set veth2b master br0
ip link set veth2b up
ip netns exec ns2 ip link set lo up
| 4.2.4、创建vxlan设备，并进行相应设置 |
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.122 local 10.211.55.123 dev eth0
ip addr add 10.244.2.0/32 dev vxlan11
ip link set vxlan11 up
| 4.2.5、进入到ns2空间里，设置去往其他网段的路由 |
ip netns exec ns2 ip route add 10.244.1.0/24 via 10.244.2.1 dev veth2a
| 4.2.6、在主命名空间下，设置去往其他VTEP设备的路由 |
ip r a 10.244.1.0/24 via 10.244.1.0 dev vxlan11 onlink
| 4.3、登录到master节点上，发起ICMP协议请求 |
ip netns exec ns1 ping -c 1 10.244.2.2
| 5、分析master节点到slave节点第一次请求时，数据包报文结构 |
| 5.1、在master节点上，对网桥进行抓包 |
tcpdump -nn -i br0
tcpdump -nn -i br0 -w br0.pcap
| 5.2、在master节点上，对vxlan11设备进行抓包 |
tcpdump -nn -i vxlan11
tcpdump -nn -i vxlan11 -w vxlan11.pcap
| 5.3、在master节点上，对eth0网卡进行抓包 |
tcpdump -nn -i eth0 port 4789
tcpdump -nn -i eth0 port 4789 -w eth0.pcap
| 5.4、在master节点上，重新发起请求 |
ip netns exec ns1 ping -c 1 10.244.2.2
分析一下网桥br0的数据包
分析一下，vxlan11设备的数据包
分析一下，eth0网卡的数据包
| 5.5、第一次请求时，传输过程中数据包报文结构变化 |
在master节点上：
- 从ns1里发起ping -c 1 10.244.2.2请求产生icmp数据包
- ICMP数据包通过veth1a到达网桥br0
- 数据包达到网桥后，通过路由等转发到了vxlan11设备
- 经过vxlan11设备后，更新了ICMP数据包的源MAC地址，目的MAC地址
- 从vxlan11出来后，linux内核将此数据包作为原始包，封装到了UDP包里，通过eth0发送出去。
而在slave节点上：
- eth0网卡接收到master节点发送过来的数据包后，发现目的MAC地址是eth0网卡的，就进行解析
- 发现此数据包带有vxlan头部，就将此UDP数据包的内部数据交由vxlan11设备处理
- vxlan11设备解析此数据包(接收的数据包是UDP里的被封装的数据，即ICMP数据包)，发现目的IP地址是10.244.2.2，经过路由判断就交由br0网桥处理
- br0网桥，将此数据包转发给veth2b,在转发给了ns2里veth2a网卡处理。
通过上面的流程，封装，解封装
我们知道内部网络ns1产生的ICMP数据包被封装到了物理网络里，通过物理网络进行的传输。
| 6、为什么说vxlan是MAC in UDP呢？(纯属个人理解) |
从对vxlan11的抓包分析，可知道，vxlan不负责创建UDP数据包，
vxlan11，至少做了一件事，更新了从网桥br0接收到数据包的源MAC，目的MAC地址。
源MAC地址变为了vxlan11自己的MAC地址
目的MAC地址变为了目的vxlan11设备的MAC地址。
| 7、分析master节点到slave节点第一次请求时，经过的iptables规则链 |
为了能够监测到iptables规则链，需要给master节点、slave节点添加日志埋点。
需要用到rsyslog服务。
参考下面的步骤，分别在master节点，slave节点上安装即可。
| 7.1、安装rsyslog（已安装，可跳过此步骤） |
| 7.1.1、安装rsyslog服务 |
yum -y install rsyslog
| 7.1.2、更新配置文件 |
echo "kern.* /var/log/iptables.log" >> /etc/rsyslog.conf
.*，表示所有等级的消息都添加到iptables.log文件里
信息等级的指定方式
- .XXX，表示 大于XXX级别的信息
- .=XXX,表示等于XXX级别的信息
- 如，kern.=notice /var/log/iptables.log, 将notice以上的信息添加到iptables.log里
- .!XXX, 表示在XXX之外的等级信息
| 7.1.3、重启rsyslog服务 |
systemctl restart rsyslog
systemctl status rsyslog
| 7.2、在master节点上添加日志埋点 |
iptables -t nat -I PREROUTING -d 10.244.2.0/24 -j LOG --log-prefix "Nat-PREROUTING-1-"
iptables -t filter -A FORWARD -d 10.244.2.0/24 -j LOG --log-prefix "Filter-FORWARD-1-"
iptables -t nat -A POSTROUTING -d 10.244.2.0/24 -j LOG --log-prefix "Nat-POSTROUTING-1-"
iptables -t nat -I PREROUTING -d 10.211.55.123 -j LOG --log-prefix "Nat-PREROUTING-2-"
iptables -t filter -A FORWARD -d 10.211.55.123 -j LOG --log-prefix "Filter-FORWARD-2-"
iptables -t nat -I OUTPUT -d 10.211.55.123 -j LOG --log-prefix "Nat-OUTPUT-2-"
iptables -t nat -A POSTROUTING -d 10.211.55.123 -j LOG --log-prefix "Nat-POSTROUTING-2-"
因为一开始，我们是不知道数据包经过哪些链的
因此，我们可以给所有的链添加日志埋点。
其实，主要是三条路线：
- PREROUTING->INPUT
- PREROUTING->FORWARD->POSTROUTING
- OUTPUT->POSTROUTING
在这三条路线上，添加上日志埋点即可。
实时查看日志变化
tail -f /var/log/iptables.log
| 7.3、在slave节点上添加日志埋点 |
iptables -t nat -I PREROUTING -p udp --dport 4789 -j LOG --log-prefix "Nat-PREROUTING-1-"
iptables -t filter -I INPUT -p udp --dport 4789 -j LOG --log-prefix "Nat-INPUT-1-"
iptables -t nat -I PREROUTING -d 10.244.2.2 -j LOG --log-prefix "Nat-PREROUTING-2-"
iptables -t nat -I OUTPUT -d 10.244.2.2 -j LOG --log-prefix "Nat-OUTPUT-2-"
iptables -t nat -A INPUT -d 10.244.2.2 -j LOG --log-prefix "Nat-INPUT-2-"
iptables -t filter -I FORWARD -d 10.244.2.2 -j LOG --log-prefix "filter-FORWARD-2-"
iptables -t nat -A POSTROUTING -d 10.244.2.2 -j LOG --log-prefix "Nat-POSTROUTING-2-"
实时查看日志变化
tail -f /var/log/iptables.log
| 7.4、在master节点上，重新发起请求 |
| 7.4.1、查看master节点上的日志 |
| 7.4.2、查看slave节点上的日志 |
| 7.5、第一次请求时，经过的iptables规则链 |
需要明白
数据包在不同设备之间进行转发时，都经过了哪些链。
| 8、整体分析一下，第1次请求时，数据包到底经过了什么才能到达对方？(仅供参考) |
在分析iptables规则链的基础上，我们进一步分析一下。
只有明白数据包到底经过了哪些设备，哪些规则链，出现问题后，才能一步一步的进行排错。
| 8.1、整体流程解剖图 |
该图主要画出了不同网络设备之间数据包转发时，主要用到了哪些知识点
比方说：
master节点上的veth1a产生的数据包到网桥br0时，主要涉及到了容器里的路由，以及ARP。
数据包从br0到vxlan11设备时，中间主要涉及到了宿主机路由，iptables规则链，以及路由转发功能ip_forward。
其他类似。
| 8.2、在master节点上，数据包从veth1a是如何到网桥br0的？ |
在ns1网络命名空间里，当发起ping -c 1 10.244.2.2命令请求后，主要发生了什么事情
ping命令产生数据包的目的地址是10.244.2.2，先通过arp查询10.244.2.2的MAC地址
从图中可以看出来，没有查询到。
即，本地没有缓存目的地址的MAC地址，因此，需要创建ARP数据包，获取目的IP的MAC地址。
目的地址跟本地地址不在同一个局域网里，本地网络是10.244.1.10/24，而目的网络是10.244.2.0/24
因此，需要将ARP数据包发送给本地网络的网关，网关地址就是网桥br0,10.244.1.1
看一下，对网桥的抓包数据
网桥收到数据包后，对其进行解析，发现是ARP包，目的地址是网桥自己的。
网桥就会将自己的MAC地址发送给veth1a
也就是说，想获取的是10.244.2.2IP的MAC地址，实际上获取到的是10.244.1.1的MAC地址。
veth1a网卡收到网桥反馈的ARP数据包后，就会创建ICMP数据包；
此时，数据包的主要报文结构内容：
- 目的IP依旧是10.244.2.2，源IP是10.244.1.2
- 目的MAC地址是网桥的MAC地址，源MAC地址是veth1a的MAC地址。
小总结：
先通过ARP协议获取目的MAC地址，
路由是设置数据包通过哪个网卡发送给哪个网络的；
因此，如果是跨网段传输的话，一定要检查是否有去往目的网络的路由
| 8.3、在master节点上，数据包从网桥br0是如何到vxlan11设备的？ |
网桥br0接收到veth1a发送过来的ICMP数据包后，对其进行解析，获取到目的MAC地址是自己的MAC地址，目的IP地址是10.244.2.2
对于网桥br0来说，它是收到的数据包(而不是通过br0发送数据包的)，因此，以PREROUTING链为开始，而非OUTPUT链。
即，
- 经过PREROUTING链
- 查看nat表的PRETROUTING链，发现此链只有一条规则DOCKER，数据包的目的地址是10.244.2.2不符合DOCKER规则中的dst-type LOCAL，
- 因此,不会匹配此规则，
- 因此，数据包最终会匹配PREROUTING链的默认规则，而默认规则是ACCEPT，因此，此数据包可以通过PREROUTING链。
- 接下来，查看宿主机上的路由表
- 去往10.244.2.2的数据包，需要通过vxlan11设备发送到10.244.2.0网段，而下一跳地址是10.244.2.0,即，就是vxlan11设备的IP地址。
- 此时，数据包已经知道去往哪个网段了，发送给哪个网卡
- 发送给vxlan11设备时，需要经过filter表的FORWARD链
- 数据包经过FORWARD链时，不会匹配FORWARD链当前的规则，因为当前规则对入网卡，或者出网卡都进行了限制，而此数据包是不满足的
- 因此，最终此数据包会匹配FORWARD链的默认规则
- 而，默认规则是ACCEPT，因此，此数据包会通过FORWARD链
- 接下来，数据包会通过nat表的POSTROUTING链
- 数据包不会匹配POSTROUTING链的规则，源IP地址不符合当前规则。
- 因此，数据包会匹配POSTROUTING链的默认规则，
- 同样，默认规则是ACCETP，因此，放行此数据包。
- 最终数据包到达了vxlan11设备
由于使用了数据包的转发，同样，需要本宿主机开启路由转发功能，即
为1，说明已经开启了。
否则,临时设置一下
echo 1 > /proc/sys/net/ipv4/ip_forward
同一个宿主机上多个网卡之间转发数据包时，需要经过PRETOUTING链，路由表，FORWARD链，POSTROUTING链 以及 开启了路由转发功能。
| 8.4、在master节点上，数据包是如何从vxlan11设备到达本机的eth0对外网卡的？ |
vxlanll设备接收到从网桥br0转发过来的ICMP数据包，发现目的IP是10.244.2.2
vxlan11会查询宿主机上的ARP表，是否有10.244.2.2对应的MAC地址
上图可以看出来，是没有的。
那么，此时，需要发送ARP协议了。
在宿主机所在的主网络命名空间下查看一下，去往10.244.2.2的路由？
即，去往10.244.2.2目的地址的ARP数据包，需要发送给10.244.2.0地址
ARP数据包的主要报文结构内容：
目的MAC地址是00:00:00:00:00:00, 源MAC地址是vxlan11设备自己的MAC地址
目的IP是10.244.2.0，源IP是vxlan11的IP，即10.244.1.0
Linux内核发现从vxlan11设备发送出ARP数据包后，会对其进行重新封装，如封装成UDP数据包，如下图所示：
而UDP数据包的报文结构内容？
Linux内核需要查看vxlan11设备的详细信息，如下：
从这里可以获取到
目的IP是10.211.55.123，源IP是10.211.55.122
查询本地路由，就知道去往10.211.55.123目的地址的数据包需要通过本地网卡eth0，即10.211.55.122发送
因此，相当于知道了以下信息：
UDP数据包的目的MAC地址就是10.211.55.123的MAC地址，
源MAC地址就是10.211.55.122的MAC地址
源端口号是本地随机产生的，目的端口是4789
被封装的数据是vxlan头部以及ARP数据包
Linux内核产生的UDP数据包的目的地址是10.211.55.123
- 查询路由
- 去往10.211.55.0网段的数据包，需要通过eth0发送
- 路由已经知道了，接下来需要通过iptables规则链
- 既然是Linux内核新产生的数据包而并非某个网卡接收或者转发的数据包，因此，首先需要经过OUTPUT链
- nat表的OUTPUT链
- 数据包的目的地址是10.211.55.123,不满足dst-type LOCAL匹配条件，因此，不会匹配DOCKER规则
- 最终会匹配OUTPUT的默认规则，而默认规则是ACCETP，因此，放行此数据包
- 接下来，经过nat表的POSTROUTING链
- 此数据包的源IP地址不满足此规则的源匹配条件172.17.0.0/16
- 最终会匹配默认规则，而默认规则是ACCEPT，因此，放行此数据包。
- 最终，Linux产生的UDP数据包到达了eth0网卡
- 通过此网卡发送出去。
即，Linux内核将vxlan11设备产生的ARP数据包封装成了UDP数据包，通过eth0网卡发送出去，UDP数据包是通过原有的网络线路传输过去的。
这里要注意一下，查询本地vxlan11设备详情，主要是获取目的vxlan11设备所在的宿主机IP的。
| 8.5、在slave1节点上，eth0网卡接收到从master节点发送过来的UDP数据包后，UDP数据包如何到达slave1节点上的vxlan11设备？ |
eth0网卡接收到从master节点发送过来的UDP数据包后，
对其进行解析，发现目的MAC地址是自己的，目的IP也是自己10.211.55.123
经过iptables规则链
- 经过nat表的PREROUTING链
- 接收到数据包会匹配成功DOCKER链，然后，进入DOCKER链的进行匹配
- 在DOCKER链里，不满足in的匹配条件，因此，会触发return
- 因此，接收到的数据包会匹配PREROUTING链的默认规则
- 而，默认规则是ACCEPT，因此，放行此数据包
- 接下来，进行路由判断,发现是目的IP是本网卡eth0，因此，需要经过nat的INPUT链了。
- INPUT链，当前没有规则。因此，直接匹配INPUT链的默认规则，
- 而，默认规则是ACCEPT,因此，放行此数据包。
- 因为，此数据包是UDP协议，交由监听4789端口的服务处理(仅个人理解，要么是Linux内核处理，要么是vxlan处理；就当Linux内核处理吧，因为在vxlan设备上抓取不到udp数据包)
- Linux内核对UDP数据包进行拆解，发现有vxlan头部标识，
- 因此，linux内核将剩下的数据发送给vxlan11设备
| 8.6、在slave1节点上，vxlan11设备接收到linux内核发送过来的数据后，如何处理？ |
vxlan11设备接收到Linux内核发送过来的数据后
也就是ARP数据，
对ARP数据包进行解析，发现目的IP是自己10.244.2.2
因此，需要对此数据包进行响应，
即，将自己的MAC地址回馈给对方。
也就是，创建一个ARP反馈包。
接下来，Linux内核会检测到vxlan11设备发送了ARP数据包，同样的原理，会添加vxlan头部，封装成UDP数据包，发送给122节点。
122节点的eth0网卡收到数据包后，会经过PRETOURINGT链，路由判断，INPUT链，
接下来，
Linux内核会对其进行解析，发现有vxlan头部，将剩下的数据交由master节点的vxlan设备
具体就不再详细的解析了。
| 8.7、在master节点上，vxlan11设备接收到slave1节点上反馈的ARP数据包后，接下来如何处理? |
vxlan11网卡接收到ARP反馈包后，即获取到了目的vxlan11设备的MAC地址
接下来，开始重新封装ICMP数据包，此报文的主要内容：
目的MAC地址就是刚从ARP响应包里获取到的MAC地址，即123节点上的vxlan11设备的MAC地址
源MAC地址就是自己的地址，即122节点的vxlan11设备的MAC地址
目的IP，就是10.244.2.2这个不变
源IP，就是10.244.1.2这个也不变。
| 8.8、在master节点上，vxlan11设备发送的ICMP数据包如何到达本节点的eth0网卡上？ |
道理跟vxlan11设备发送ARP数据包时是一样的。
Linux内核监测到vxlan11设备发送数据包后，会自动给此数据包添加一个vxlan头部
因为，从vxlan11设备详情里已经知道，vxlan11设备发送的数据包的目的IP是10.211.55.123
因此，Linux内核将vxlan11设备发送的数据包重新封装后的UDP数据包的主要内容：
- 目的MAC是123节点的MAC地址，源MAC地址是122节点的MAC地址
- 目的IP是10.211.55.123，源IP是10.211.55.122
- 目的端口是4789，源端口是随机产生的。
- 被封装的数据是vxlan头部以及ICMP数据包
Linux内核创建的UDP数据包，先经过路由判断，获取到去往10.211.55.123节点的数据包，需要由本地的eth0网卡发送。
同样会经过nat表的OUTPUT链，nat表的POSTROUTING链。(不再，展示图了，跟上面发送ARP时是一样的)
Linux内核产生的UDP数据包(此数据包，携带者ICMP数据包)，最终到达了本地的eth0网卡；
本地网卡eth0会将此数据包通过原来的网络发送给123节点的eth0网卡。
| 8.9、在slave1节点上，eth0网卡接收到master节点发送的UDP数据包(携带ICMP数据包)后，如何处理？ |
其实，整个处理过程，跟上面处理ARP时，完全一样的。
eth0网卡接收到数据包后，判断目的MAC地址是否是自己。发现是自己的MAC地址，
接下来，经过nat表的PREROUTING链，然后，经过路由判断，
继续经过nat表的INPUT链，此数据包是UDP类型的数据包，发现目的端口是4789
因此，需要交由监听4789的服务处理，
即，Linux内核对此数据包进行解析，发现还有vxlan头部
因此，Linux内核将剩下的数据，转发给了slave1节点的vxlan11设备。
| 8.10、在slave1节点上，vxlan11设备如何处理Linux转发过来的数据？是如何发送到网桥br0的？ |
vxlan11设备接收到Linux内核转发过来的数据后，对其进行解析
发现目的MAC地址，就是自己。而目的IP地址是10.244.2.2，并非自己。
- 接下来需要经过nat表PREROUTING链:
- 此，数据包的目的IP地址不满足dst-type LOCAL匹配条件
- 因此，会匹配PREROUTING链的默认规则，而，默认规则是ACCEPT，因此，放行此数据包
- 然后，进行路由判断，
- 去往10.244.2.2的数据包，需要通过br0网桥发送到10.244.2.0网段
- 因此，接下来需要匹配filter表的FORWARD链
- 此数据包是通过vxlan11设备接收到的，需要转发给br0网桥，即in是vxlan11,out是br0；因此，不满足FORWARD链里的规则。
- 最终会匹配FORWARD链的默认规则，而默认规则是ACCEPT，因此，放行此数据包。
- 接下来匹配nat表的POSTROUTING链
- 此数据包的目的IP是10.244.2.2 因此，不匹配POSTROUTING链的规则
- 因此，最终会匹配POSTROUTING链的默认规则，同样，默认规则是ACCEPT，放行此数据包
- 最终，从vxlan11出来的数据包到达了网桥br0
同样，不同网卡之间进行路由转发时，需要查看是否开启了路由转发功能？
more /proc/sys/net/ipv4/ip_forward
查看是否是1
不同网卡之间数据包转发的主要流程
vxlan11—>PREROUTING—>路由判断—>FORWARD—>POSTROUTING—>br0
br0收到vxlan11设备的数据包的报文结构
目的MAC地址是br0的MAC地址，源MAC地址是vxlan11设备的MAC地址
目的IP是10.244.2.2，源IP是10.244.1.2
协议是ICMP
| 8.11、在slave1节点上，数据包到达网桥br0如何到达最终的目的网卡veth2a？ |
从vxlan11设备发送的数据包到达br0网桥后，
br0网桥会对此数据包进行解析，发现目的IP是10.244.2.2
会查询本地ARP表，如果没有的话，同样会创建ARP数据包，发送到本网桥管理的局域网里，
即，给ns2网络里的veth2a网卡也发送了arp数据包。
从上面的图，可以看出来，一开始是没有的。
master节点的ns1里发送ping请求后，slave1节点才添加到。
网桥br0获取到目的IP10.244.2.2的MAC地址后，会重新封包
(需要更新源MAC地址为网桥br0的MAC地址，目的MAC地址改为10.244.2.2的MAC地址；IP信息不变)
然后，网桥br0通过内部管理的veth2b网卡，将数据包发送给了ns2里的veth2a。
veth2a跟veth2b是一一对veth pair
| 8.12、总结 |
到此为止，我们整体分析了在master节点的ns1网络命名空间里发起的ping -c 1 10.244.2.2请求
产生的数据包是如何一步一步的到达目的网卡的。
反馈过程，很类似，就不再一一解析了。
需要注意一点是，反馈过程，以及后续的第n次请求时，可能不会再经过nat表了。
即，不会经过nat表的INPUT，PREROUTING，POSTROUITNG链了。（原因不是很了解，不在详细研究。可能是为了提高效率吧）
在网络通信时，需要重点关注以下几点：
- ARP协议，用来获取目的MAC地址的；
- ARP协议不能跨网段使用，出网段时，只能交由网关，
- 网关会将自己的MAC地址发送给ARP请求的发起者；
- 接下来，由网关发起新的ARP请求，发送给下一跳地址。
- 直到获取到目的MAC地址
- 路由，需要关心下一跳的地址，通过哪个网卡设备发送出去的
- vxlan设备，需要关心对端的地址是多少？监听的是哪个端口？4789？
- 不同网卡之间进行数据包转发时，需要经过哪些链？
- 路由转发功能是如何开启的？
备注：
上面分析中，涉及到INPUT链、OUTPUT链的时候，说的不是很全。
只说了NAT表下的INPUT链，OUTPUT链。
大家在实际分析的时候，可以自己再添加上对filter表下的INPUT链，OUTPUT链分析即可。
| 9、提供完整的操作命令 |
| 9.1、master节点上 |
ip netns add ns1
ip link add br0 type bridge
ip addr add 10.244.1.1/24 dev br0
ip link set br0 up
ip link add veth1a type veth peer name veth1b
ip link set veth1a netns ns1
ip netns exec ns1 ip address add 10.244.1.2/24 dev veth1a
ip netns exec ns1 ip link set veth1a up
ip link set veth1b master br0
ip link set veth1b up
ip netns exec ns1 ip link set lo up
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.123 local 10.211.55.122 dev eth0
ip addr add 10.244.1.0/32 dev vxlan11
ip link set vxlan11 up
ip netns exec ns1 ip route add 10.244.2.0/24 via 10.244.1.1 dev veth1a
ip r a 10.244.2.0/24 via 10.244.2.0 dev vxlan11 onlink
| 9.2、slave节点 |
ip netns add ns2
ip link add br0 type bridge
ip addr add 10.244.2.1/24 dev br0
ip link set br0 up
ip link add veth2a type veth peer name veth2b
ip link set veth2a netns ns2
ip netns exec ns2 ip address add 10.244.2.2/24 dev veth2a
ip netns exec ns2 ip link set veth2a up
ip link set veth2b master br0
ip link set veth2b up
ip netns exec ns2 ip link set lo up
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.122 local 10.211.55.123 dev eth0
ip addr add 10.244.2.0/32 dev vxlan11
ip link set vxlan11 up
ip netns exec ns2 ip route add 10.244.1.0/24 via 10.244.2.1 dev veth2a
ip r a 10.244.1.0/24 via 10.244.1.0 dev vxlan11 onlink
| 9.3、登录到master节点上 测试 |
ip netns exec ns1 ping -c 1 10.244.2.2
| 10、wireshark如何解析vxlan数据包 |
| 10.1、修改默认wireshark解析vxlan数据包的端口 |
当前使用wireshark的版本号
wireshark是可以解析vxlan协议的。
wireshark解析vxlan协议时，默认用到的端口号是4789，即wireshark认为4789端口的数据包为vxlan协议数据包。
但是，我们使用的vxlan端口是8472，因此，需要修改wireshark中解析vxlan的端口号。
2023年06.04
再重新提供一版
| 11、新的版本 |
| 11.1、122节点 |
ip netns add ns1
ip link add br0 type bridge
ip addr add 10.244.1.1/24 dev br0
ip link set br0 up
ip link add veth1a type veth peer name veth1b
ip link set veth1a netns ns1
ip netns exec ns1 ip address add 10.244.1.2/24 dev veth1a
ip netns exec ns1 ip link set veth1a up
ip link set veth1b master br0
ip link set veth1b up
ip netns exec ns1 ip link set lo up
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.123 local 10.211.55.122 dev eth0
ip addr add 10.244.1.0/32 broadcast 10.244.1.255 dev vxlan11
ip link set vxlan11 up
ip netns exec ns1 ip route add 10.244.2.0/24 via 10.244.1.1 dev veth1a
ip r a 10.244.2.0/24 via 10.244.2.0 dev vxlan11 onlink
| 11.2、123节点 |
ip netns add ns2
ip link add br0 type bridge
ip addr add 10.244.2.1/24 dev br0
ip link set br0 up
ip link add veth2a type veth peer name veth2b
ip link set veth2a netns ns2
ip netns exec ns2 ip address add 10.244.2.2/24 dev veth2a
ip netns exec ns2 ip link set veth2a up
ip link set veth2b master br0
ip link set veth2b up
ip netns exec ns2 ip link set lo up
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.122 local 10.211.55.123 dev eth0
ip addr add 10.244.2.0/32 broadcast 10.244.2.255 dev vxlan11
ip link set vxlan11 up
ip netns exec ns2 ip route add 10.244.1.0/24 via 10.244.2.1 dev veth2a
ip r a 10.244.1.0/24 via 10.244.1.0 dev vxlan11 onlink
| 11.3、登录到122节点上，重新测试 |
ip netns exec ns1 ping -c 1 10.244.2.2
| 12、新的版本2 |
| 12.1、122节点 |
ip netns add ns1
ip link add br0 type bridge
ip addr add 10.244.1.1/24 dev br0
ip link set br0 up
ip link add veth1a type veth peer name veth1b
ip link set veth1a netns ns1
ip netns exec ns1 ip address add 10.244.1.2/24 dev veth1a
ip netns exec ns1 ip link set veth1a up
ip link set veth1b master br0
ip link set veth1b up
ip netns exec ns1 ip link set lo up
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.123 local 10.211.55.122 dev eth0
ip addr add 10.244.1.0/32 broadcast 10.244.1.0 dev vxlan11
ip link set vxlan11 up
ip netns exec ns1 ip route add 10.244.2.0/24 via 10.244.1.1 dev veth1a
ip r a 10.244.2.0/24 via 10.244.2.0 dev vxlan11 onlink
| 12.2、123节点 |
ip netns add ns2
ip link add br0 type bridge
ip addr add 10.244.2.1/24 dev br0
ip link set br0 up
ip link add veth2a type veth peer name veth2b
ip link set veth2a netns ns2
ip netns exec ns2 ip address add 10.244.2.2/24 dev veth2a
ip netns exec ns2 ip link set veth2a up
ip link set veth2b master br0
ip link set veth2b up
ip netns exec ns2 ip link set lo up
ip link add vxlan11 type vxlan id 11 dstport 4789 remote 10.211.55.122 local 10.211.55.123 dev eth0
ip addr add 10.244.2.0/32 broadcast 10.244.2.0 dev vxlan11
ip link set vxlan11 up
ip netns exec ns2 ip route add 10.244.1.0/24 via 10.244.2.1 dev veth2a
ip r a 10.244.1.0/24 via 10.244.1.0 dev vxlan11 onlink
| 12.3、登录到122节点上重新测试 |
ip netns exec ns1 ping -c 1 10.244.2.2
<<零入门kubernetes网络实战>>技术专栏之文章目录
