Qu'est-ce qui empêche un client DHCP d'obtenir l'itinéraire de passerelle par défaut?

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

Le problème vient de ce que Linux semble avoir dépouillé la passerelle ["(4) Routeurs" dans dhcpdump] dans la réponse DHCP. OpenVPN documents ceci comme suit:

Si --server-bridge est utilisé sans aucun paramètre, il activera une   Mode proxy DHCP, où les clients OpenVPN connectés recevront une adresse IP   adresse de leur adaptateur TAP à partir du serveur DHCP exécuté sur le   OpenVPN LAN côté serveur. Notez que seuls les clients prenant en charge la   la liaison d’un client DHCP avec l’adaptateur TAP (tel que Windows) peut   supporte ce mode . Le drapeau optionnel nogw (avancé) indique que   Les informations de passerelle ne doivent pas être transmises au client.

Alors, en utilisant nogw semblait n'avoir aucun effet sur le pi - comme prévu puisqu'il s'agit de Linux. Mais lorsque je connecte un ordinateur (tout type de client: Linux ou Windows) au port Ethernet du pi, une passerelle lui est affectée. En d’autres termes, la réponse DHCP du serveur TAP'd est transmise sans modification aux clients de l’autre côté du pi, mais pas au pi lui-même. Cette dernière partie convient parfaitement car elle possède ses propres scripts de configuration, etc.

Le point et le résultat est le suivant: tous les clients génériques peuvent se connecter au pi en tant que routeur connecté de manière sécurisée à un serveur VPN. TAP sans aucun problème.