Himbeer-PI ist über TAP-Verbindung mit dem OpenVPN-Server verbunden. Der Anschluss von PI ist mit der Ethernet-Schnittstelle des PI überbrückt.
Wenn der fragliche Client eine Verbindung zum Ethernet-Port des pi herstellt, wird der isc-dhcp-server auf dem OpenVPN-Server sofort abgefragt und weist eine IP-Adresse zu. Der Client übernimmt die IP-Adresse ohne Probleme. Er hat jedoch in seiner Routentabelle absolut kein 'Default Gateway via ...'. Wenn ich die Route manuell eingebe, indem Sie Folgendes eingeben:
ip route add default via 10.70.0.1 def eth0
Dann funktioniert der Client einwandfrei.
Beachten Sie, dass dies keine herkömmliche TUN-VPN-Verbindung ist. Dies ist eine TAP-Verbindung und der VPN-Client ist der Raspberry PI, der sich zwischen dem Client und dem Server befindet. Also spielt kein Route-Pushing oder Gateway-Pushing durch OpenVPN überhaupt eine Rolle.
PI bei Verbindung zum OpenVPN-Server:
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
Client, wenn er mit dem PI verbunden ist:
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
Beachten Sie auch, dass die RAs für IPv6 einwandfrei funktionieren (ebenso das Routing). Werfen wir dies einfach als Beweis dafür, dass die Brücken wie erwartet funktionieren. Diese IPv6-Adressen sind alle Teil des IPv6-Routing-Blocks des Servers. Diese 8723-Adresse ist wie erwartet die IPv6-LL-Adresse des Servers.
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
Der Client funktioniert erwartungsgemäß, wenn er an einen anderen Router angeschlossen wird. Es erhält seine IP-Adresse UND die "Standard-Via". Ich gehe davon aus, dass sich die Brücke nach dem Bau der Brücke zwischen Server und Client so verhalten sollte, als wäre alles physisch miteinander verbunden. Und fast schon. Kein Routing sollte in diese Gleichung einfließen, aber wenn jemand fragt, ist iptables im Accept All-Modus, bis ich das herausgefunden habe.
DHCP-Server (ich habe dieselbe Konfiguration mehrmals ohne Probleme verwendet):
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; }