排查并解决VPN访问内网的路由不对称问题

背景：问题的起源与链路

最近我在通过VPN访问公司内网时遇到了一个奇怪的问题：配置了两个内网子网，其中192.168.10.55可以正常访问，而192.168.20.166无法访问，但同一子网的192.168.20.254却没问题。这让我困惑不已，于是开始了排查之旅。

问题链路如下：

• 客户端：我的电脑通过VPN（IP: 10.10.10.2）连接内网。
• 目标服务器：一台Ubuntu 22.04服务器（IP: 192.168.20.163，问题中提到的166类似，后续以163为例）。
• 内网设备：
  • 交换机（Waiwang_S5560_HX，IP: 192.168.20.254）。
  • 中间路由设备（IP: 192.168.100.2）。
• 现象：VPN能ping通192.168.20.254和192.168.20.123，但192.168.20.163超时。

---

分析过程：从现象到假设

从我的初始描述开始，逐步深入：

1. 路由表检查
   我测试了客户端的route print，显示192.168.20.0/24的流量通过VPN接口（10.10.10.2）路由，表面上没问题。可能是目标设备的防火墙或内网路由问题。

2. Traceroute对比

   • tracert 192.168.20.254成功，直接到达。
   • tracert 192.168.20.123成功，经过192.168.100.2。
   • tracert 192.168.20.163超时在192.168.100.2。
     推测问题出在192.168.100.2之后的路径，可能是ACL或路由配置。

3. 内网连通性验证
   我在交换机上测试，ping 192.168.20.163和tracert 192.168.20.163都成功，说明163在线且内网正常。调整假设：问题可能在VPN到163的回程。

4. 服务器网络配置
   163上用Docker的macvlan创建了子接口（192.168.10.111），这可能不直接影响192.168.20.163，但还是需要检查163的路由表。

5. 路由不对称的发现
   163的ip route显示有两个默认网关：

   • default via 10.40.92.1 dev enp4s0（有线网卡）。
   • default via 192.168.20.254 dev wlp3s0（无线网卡，metric 600）。
     由于metric较低，有线网卡优先，导致回程流量走10.40.92.1，而非VPN期望的192.168.20.254。

---

测试过程：步步为营

1. 客户端路由验证

   • 检查route print，确认192.168.20.0/24走VPN接口。
   • tracert 192.168.20.163，超时在192.168.100.2。

2. 内网连通性测试

   • 交换机上ping 192.168.20.163，成功。
   • tracert 192.168.20.163，一步到达。

3. 163服务器检查

   • 确认防火墙关闭：sudo ufw status显示inactive。
   • 查看路由：ip route，发现多默认网关问题。
   • 测试macvlan影响：ping 10.10.10.2 -I 192.168.20.163，不通。

4. 交换机路由表

   • display ip routing-table，有192.168.20.0/24路由，下一跳192.168.20.254。
   • display acl all，无ACL规则。

5. 临时路由调整

   • 在163上添加：sudo ip route add 10.10.10.0/24 via 192.168.20.254 dev wlp3s0。
   • VPN客户端ping 192.168.20.163，成功！

---

解决方案：修复路由不对称

问题根源

163服务器插了一根网线，连接路由器分配了10.40.92.1的默认网关。由于metric较低，163的回程流量走10.40.92.1，而非VPN期望的192.168.20.254，导致VPN客户端无法收到回应。

解决方法

在163（Ubuntu 22.04）上永久添加静态路由：

1. 编辑Netplan配置文件：

   sudo vi /etc/netplan/01-netcfg.yaml

   修改为：

   network:
     version: 2
     ethernets:
       wlp3s0:
         addresses:
           - 192.168.20.163/24
         gateway4: 192.168.20.254
         routes:
           - to: 10.10.10.0/24
             via: 192.168.20.254
       enp4s0:
         addresses:
           - 10.40.92.26/24

2. 应用配置：

   sudo netplan apply

3. 验证：

   ip route
   ping 10.10.10.2

这样，VPN流量走192.168.20.254，其他流量仍可走10.40.92.1。

---

网络知识总结

1. 路由表与Metric

   • Linux中，ip route列出的metric值决定路由优先级。值越低，优先级越高。我的163服务器上有线网卡（metric默认较低）优先于无线网卡（metric 600），导致流量走错路径。
   • 原理：内核选择metric最低的路由，若metric相等，则负载均衡或随机选择。

2. 路由不对称

   • 去程和回程路径不一致会导致通信失败。VPN要求流量双向通过隧道，但163的回程走外部路由器，数据包丢失。

3. VPN与子网路由

   • VPN客户端依赖服务器推送的路由表（如192.168.20.0/24）。若目标设备回程路由不匹配，通信中断。

4. macvlan的影响

   • Docker的macvlan创建独立子接口（如192.168.10.111），但不影响宿主IP（192.168.20.163），除非配置干扰默认路由。

5. H3C交换机命令

   • display ip routing-table查看路由，display acl all检查访问控制，类似Cisco但语法略异。

---

工作中的启示

1. 多网卡需谨慎
   服务器接多个网络（如有线+无线）易引发路由冲突。配置时明确指定流量路径，避免默认路由干扰。

2. 逐步排查是关键
   从客户端到目标，逐段测试（route、tracert、ping），结合设备配置，才能精准定位。

3. 理解网络优先级
   Metric值虽小却影响大，忽视它可能埋下隐患。配置时要检查所有网卡的路由规则。

4. 日志与工具并用
   使用tcpdump、ip route等工具，能更快发现不对称问题，避免盲目猜测。

5. 文档化经验
   这次排查耗时不短，记录过程不仅加深理解，还能为团队提供参考。

---

结语

这次问题的根源看似复杂，最终却是一个简单的路由配置失误。解决了VPN访问难题，还学到了网络排查的系统方法。希望这篇博客能帮到遇到类似问题的你，也欢迎交流你的经验！

---

• 本文作者： Linking
• 本文链接： https://linking.fun/2023/05/20/排查并解决vpn访问内网的路由不对称问题/
• 版权声明： 版权所有，转载请注明出处！