☰

Linux、Quagga 和 OpenVPN 的棘手路由问题

tag-icon • tag-icon linux routing openvpn ospf quagga
Linux、Quagga 和 OpenVPN 的棘手路由问题

设置

我有一个充当中央路由器的 OpenVPN 服务器。它使用“拓扑子网”命令进行配置。客户端是 Debian Linux 节点，每个节点都有一个（或多个）子网直接与其连接。

目标是使连接到 VPN 的任何客户端都能够访问每个其他客户端后面连接的子网。

为了传播路由信息，我们在客户端和服务器上安装了 Quagga。使用 OSPF 守护程序可以很好地完成此操作。所有客户端和服务器上都启用了路由。

路由表

服务器上的路由表如下：

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.2.10.1       10.8.0.4        255.255.255.255 UGH   20     0        0 tun0
192.168.100.0   10.8.0.4        255.255.255.0   UG    20     0        0 tun0
192.168.1.0     10.8.0.4        255.255.255.0   UG    20     0        0 tun0

我想要访问的子网是 192.168.100.0/24。相关网关响应正常，我可以正常连接。

我认为这不会有任何用处，但这是客户端路由表的一部分：

10.2.10.1       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

事情开始变糟的地方

从服务器 (10.8.0.1) ping 192.168.100.0/24 子网中的任何主机（包括 VPN 客户端接口）均失败。如果我在 VPN 客户端上对 tun 接口进行 tcpdump，则看不到相关数据包。如果我在 VPN 服务器上对 tun 接口进行 tcpdump，则会看到相关数据包已发送出去。

真正棘手的是，当我跟踪路由到 192.168.100.0 子网中的有效 IP 时，它没有发现任何跳数（应该只有一个）。如果我直接跟踪路由到下一跳（10.8.0.4），它会正常响应。

我真的希望我说清楚了，因为这是一个相当复杂的问题。我很乐意根据您的要求提供更多信息。

答案1

我觉得奇怪的是，客户端的路由表指向任何地方（0.0.0.0）。对于本地网络来说，这没问题，但对于通过隧道的 10.2.10.1 来说，这可能是一个问题。

答案2

我原本以为，指向 VPN 隧道的默认路由足以让客户端能够路由到其他客户端（只要 VPN 集中器允许），而无需在各个客户端上运行路由守护程序。

查看路由表，我怀疑问题在于路由更新中携带的“下一跳”对于客户端来说是不可达的，因此它没有忽略该路由，而是使用未知的下一跳来安装它。

如果您停用 Quagga 并仅使用指向 VPN 隧道的默认路由，会发生什么情况？

答案3

我最终使用了“client-config-dir”，它允许我使用“iroute”命令指定每个客户端后面的路由。

之后，我让 VPN 服务器将所有这些子网的路由推送到所有其他客户端，并且运行正常。

相关内容