Raspberry PI est connecté au serveur OpenVPN via une connexion TAP. Le robinet de PI est relié à l'interface Ethernet de PI.
Lorsque le client en question se connecte au port Ethernet du pi, le serveur isc-dhcp-server sur le serveur OpenVPN est immédiatement interrogé et attribue une adresse IP. Le client prend l'adresse IP sans aucun problème. Cependant, il n'a absolument aucune "passerelle par défaut via ..." dans son tableau de routage. Si j'ajoute manuellement l'itinéraire en entrant:
ip route add default via 10.70.0.1 def eth0
Ensuite, le client fonctionne parfaitement.
N'oubliez pas qu'il ne s'agit pas d'une connexion TUN VPN traditionnelle. Il s’agit d’une connexion TAP et le client VPN est le Raspberry PI qui se situe entre le client et le serveur. Donc, aucune route poussant ou passerelle poussant par OpenVPN ne joue dans rien de tout cela.
PI lorsqu'il est connecté au serveur 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
Client connecté au 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
Notez également que les RA pour IPv6 fonctionnent parfaitement (ainsi que le routage). Il suffit de jeter cela ici comme preuve supplémentaire que les ponts fonctionnent comme prévu. Ces adresses IPv6 font toutes partie du bloc routé IPv6 du serveur. L'adresse 8723 ci-dessous est l'adresse IPv6 LL du serveur, comme prévu.
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
Le client fonctionne comme prévu lorsqu'il est branché sur un autre routeur. Il obtient son adresse IP ET le «défaut via». Mon attente est qu’une fois que le pont a été créé entre le serveur et le client, il devrait se comporter comme si tout était physiquement connecté. Et c'est presque le cas. Aucun routage ne devrait jouer dans cette équation, mais si quelqu'un le demande, iptables est en mode Accepter tout jusqu'à ce que je sache ce qu'il en est.
Serveur DHCP (j'ai utilisé cette même configuration plusieurs fois sans problème):
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;
}
routers
option de la réponse DHCP, lors du transfert des paquets entre l’interface tap et le tunnel. Pour quelque raison que ce soit (probablement parce qu'OpenVPN peut également configurer des itinéraires lorsque la connexion est établie et qu'il ne souhaite pas que les réponses DHCP annulent ces itinéraires).