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; }