Linux 网络协议栈数据流跟踪-静态路由demo
内容
实现一个demo，来学习静态路由规则，使用静态路由，来使得通过WAN口互联的两个路由器，他们lan侧分别下挂两个路由器的pc1和pc2，能够互ping通
为什么这么做？
- 这是一个非常经典且实用的网络实验，可以用来深理解路由的原理
实践设备需求：
- 两台基于linux 路由器
- 两台windows PC
框架拓扑图
配置如上图
流程分析
当PC1 (192.168.10.2) 想要Ping PC2 (192.168.20.2) 时，会发生什么？
- PC1检查目标IP 192.168.20.2，发现不在自己的 192.168.10.0/24 网段，于是将数据包发给自己的网关192.168.10.1
- AR1 收到数据包，查看自己的路由表，只知道：
直连网络 192.168.10.0/24 (LAN口)
直连网络 192.168.100.0/30 (WAN口)
却不知道 192.168.20.0/24 在哪里。 - 这里数据包传输就会出现两种选择：
1）传给默认网关
2）传给静态路由
如果都没有，AR1会直接将数据包丢弃，并回复一个Unreachable的ICMP错误
数据包流向分析
- 当PC1 Ping PC2时，数据包的流程：
PC1 -> AR1:
源IP: 192.168.10.2
目标IP: 192.168.20.2
PC1发现目标不在本地网络，将包发给网关 192.168.10.1 - AR1 处理:
AR1收到包，查看目标IP 192.168.20.2
查询路由表，匹配到我们添加的静态路由 192.168.20.0/24 via 192.168.100.2
它将数据包从WAN口 (192.168.100.1) 转发出去，目标是下一跳 192.168.100.2 (AR2) - AR2 处理:
AR2从WAN口收到这个包，查看目标IP 192.168.20.2
它发现这个IP在自己的直连网络 192.168.20.0/24 (LAN口) 上
它将数据包从LAN口转发给PC2 192.168.20.2 - PC2 回复 PC1:
PC2收到Ping请求，准备回复。回复包的源IP是 192.168.20.2，目标IP是 192.168.10.2
PC2发现目标不在本地网络，将回复包发给自己的网关 192.168.20.1 (AR2)
AR2查询路由表，匹配到静态路由 192.168.10.0/24 via 192.168.100.1
它将回复包从WAN口转发给 192.168.100.1 (AR1)
AR1收到包，发现目标 192.168.10.100 在自己的直连网络，于是通过LAN口将包最终送达PC1
所以，我们在这做这个让静态路由的实践时，我们应该让默认网关不生效！
选择静态路由方案
添加静态路由规则：我们需要在双方的路由器上手动带领它们如何去往对方所在的局域网。
- 使得默认网关不生效：
AR1配置成192.168.100.3这个无效网关
AR2配置成192.168.100.4这个无效网关
- 连通性检测：
不通，正常，因为没有正确的路径选择 - 在 AR1 上添加一条静态路由：
目的网络： 192.168.20.0 (这是PC2所在的网段)
子网掩码： 255.255.255.0
下一跳地址： 192.168.100.2 (你要去192.168.20.0/24，请把数据包交给对面的AR2的WAN口)
解释： 所有发往 192.168.20.0/24 的流量，请转发给 192.168.100.2。 - 在 AR2 上添加一条静态路由：
目的网络： 192.168.10.0 (这是PC1所在的网段)
子网掩码： 255.255.255.0
下一跳地址： 192.168.100.1 (你要去192.168.10.0/24，请把数据包交给对面的Router A的WAN口)
解释： 所有发往 192.168.10.0/24 的流量，请转发给 192.168.100.1。 - 规则命令查询
AR1：
AR2：
- 连通性检测：
注意，因为是实体设备，WAN口是无法进行ping包进入的，所以我们需要清空一下防火墙：
结果：
疑问？
- 默认网关可以解决80%的网络到达问题，为什么还要使用静态路由呢？
我们的Demo正是为了理解这背后的原理，当您将来遇到那些复杂网络拓扑、多路径网络等20%的特殊场景时，就知道如何应对了。
