Raspberry PI подключается к серверу OpenVPN через соединение TAP. Отвод ПИ соединен с Ethernet-интерфейсом ПИ.
Когда рассматриваемый клиент подключается к порту Ethernet pi, isc-dhcp-server на сервере OpenVPN немедленно получает опрос и назначает IP-адрес. Клиент берет IP-адрес без каких-либо проблем. Тем не менее, он не имеет абсолютно никакого «шлюза по умолчанию через ...» в своей таблице маршрутов. Если я вручную добавлю маршрут, введя:
ip route add default via 10.70.0.1 def eth0
Тогда клиент работает отлично.
Имейте в виду, что это не традиционное соединение TUN VPN. Это соединение TAP, а VPN-клиент - это Raspberry PI, который находится между клиентом и сервером. Таким образом, ни перетаскивание маршрутов, ни проталкивание шлюзов OpenVPN ни на что не влияет.
PI при подключении к серверу OpenVPN:
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
Также обратите внимание, что RA для IPv6 работают отлично (как и маршрутизация). Просто добавьте это в качестве еще одного доказательства того, что мосты работают как положено. Все эти адреса IPv6 являются частью маршрутизируемого блока IPv6 Сервера. Этот 8723-адрес, указанный ниже, является ожидаемым LL-адресом сервера IPv6.
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 находится в режиме Accept All, пока я не выясню это.
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;
}