☰

什么原因阻止 DHCP 客户端获取默认网关路由？

tag-icon • tag-icon ubuntu openvpn raspberry-pi dhcp-server
什么原因阻止 DHCP 客户端获取默认网关路由？

Raspberry PI 通过 TAP 连接连接到 OpenVPN 服务器。PI 的 tap 与 PI 的以太网接口桥接。

当有问题的客户端连接到 pi 的以太网端口时，OpenVPN 服务器上的 isc-dhcp-server 会立即被轮询并分配一个 IP 地址。客户端毫无问题地获取了 IP 地址。但是，他的路由表中绝对没有“通过... 的默认网关”。如果我通过输入以下内容手动添加路由：

ip route add default via 10.70.0.1 def eth0

然后客户端就可以完美运行了。

请记住，这不是传统的 TUN VPN 连接。这是一个 TAP 连接，VPN 客户端是位于客户端和服务器之间的 Raspberry PI。因此，OpenVPN 的路由推送或网关推送根本不会涉及任何这些。

连接到 OpenVPN 服务器时的 PI：

root@pi-test:~# ip addr show br0
5: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96:d5:0f:08:f3:30 brd ff:ff:ff:ff:ff:ff
    inet 10.70.0.201/24 brd 10.70.0.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2600:xxxx:xxxx:xxxx:94d5:fff:fe08:f330/64 scope global mngtmpaddr dynamic 
       valid_lft 86200sec preferred_lft 14200sec
    inet6 fe80::94d5:fff:fe08:f330/64 scope link 
       valid_lft forever preferred_lft forever

root@pi-test:~# brctl show
bridge name bridge id          STP enabled  interfaces
       br0  8000.96d50f08f330  no           eth0
                                            tap0

客户端连接到PI时：

me@client:~$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:12:3f:82:92:38 brd ff:ff:ff:ff:ff:ff
    inet 10.70.0.105/24 brd 10.70.0.255 scope global dynamic noprefixroute eth0
       valid_lft 31065sec preferred_lft 31065sec
    inet6 2600:xxxx:xxxx:xxxx:c040:ebd3:1619:57b1/64 scope global temporary dynamic 
       valid_lft 86066sec preferred_lft 14066sec
    inet6 2600:xxxx:xxxx:xxxx:d7f9:41bf:a910:9b43/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86066sec preferred_lft 14066sec
    inet6 fe80::cfce:6b01:c5d4:ced6/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

me@client:~$ ip route
default via 10.70.0.1 dev eth0 (this line is missing)
10.70.0.0/24 dev eth0 proto kernel scope link src 10.70.0.105 metric 100

还要注意的是，IPv6 的 RA 运行正常（路由也是如此）。这只是进一步证明网桥按预期运行的证据。这些 IPv6 地址都是服务器 IPv6 路由块的一部分。下面的 8723 地址是服务器的 IPv6 LL 地址，正如预期的那样。

me@client:~$ ip -6 route
2600:xxxx:xxxx:xxxx::/64 dev eth0 proto ra metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::d8ae:1bff:fe1f:8723 dev eth0 proto ra metric 100 pref medium

插入另一个路由器后，客户端可以正常工作。它获取其 IP 地址和“默认通过”。我的期望是，一旦在服务器和客户端之间建立桥接，它应该表现得好像一切都物理连接一样。而且，它几乎做到了。没有路由应该参与这个等式，但如果有人问，iptables 处于接受所有模式，直到我弄清楚为止。

DHCP 服务器（我已多次使用相同的配置，没有问题）：

root@server:~# cat /etc/dhcp/dhcpd.conf
option domain-name "local.net";
option domain-name-servers 10.70.0.1;
ddns-update-style none;
subnet 10.70.0.0 netmask 255.255.255.0 {
        range 10.70.0.100 10.70.0.199;
        option routers 10.70.0.1;
}

host pi-router1 {
        hardware ethernet 96:d5:0f:08:f3:30;
        fixed-address 10.70.0.201;
}

答案1

问题源于 Linux 似乎在 DHCP 响应中删除了网关 [dhcpdump 中的“(4) 路由器”]。OpenVPN文件如下：

如果使用 --server-bridge 而不使用任何参数，它将启用 DHCP 代理模式，其中连接的 OpenVPN 客户端将从在 OpenVPN 服务器端 LAN 上运行的 DHCP 服务器接收其 TAP 适配器的 IP 地址。请注意，只有支持将 DHCP 客户端与 TAP 适配器绑定的客户端（例如 Windows）才能支持此模式。可选的 nogw 标志（高级）表示不应将网关信息推送到客户端。

那么，使用诺格似乎对 pi 没有影响 - 因为它是 Linux，所以这是意料之中的。但是当我将计算机（任何类型的客户端：Linux 或 Windows）连接到 pi 的以太网端口时，它实际上被分配了一个网关。换句话说，来自 TAP'd 服务器的 DHCP 响应未经编辑就传到了 pi 另一侧的客户端，只是 pi 本身没有。最后一部分完全没问题，因为它有自己的配置脚本等等。

要点和结果是：任何通用客户端都可以将 pi 作为路由器连接到 VPN 服务器，并且它们都将从 TAP 另一端的 VPN 服务器分配 IP 地址（v4 和 v6），没有任何问题。

相关内容