Cette adresse L2TP est IPCP, pas un bail DHCP sur le LAN

La connexion monte et l’adaptateur affiche une adresse dans la plage du bureau, donc la conclusion naturelle est que le VPN vous a donné une adresse LAN et vous a ainsi placé sur le LAN. Aucune des deux moitiés n’est tout à fait juste. L2TP transporte une session PPP, et PPP négocie l’adresse IPv4 interne avec IPCP. Cette adresse est un paramètre de session convenu entre deux pairs, pas un bail délivré par le serveur DHCP du bureau, et la détenir ne fait pas de vous un voisin sur le câble du bureau.

Deux adresses dans une connexion

Il y a deux négociations indépendantes dans une connexion L2TP. L’externe établit un chemin protégé entre votre appareil et le point de terminaison VPN sur le réseau que vous avez déjà. L’interne est la session PPP, et c’est là que sont convenues l’adresse de votre session et celle de l’autre extrémité. Le trafic Internet peut sortir sous une troisième adresse tout à fait, l’adresse publique du point de terminaison, ce qui explique pourquoi une page de contrôle VPN et l’adresse de l’adaptateur concordent rarement.

Garder ces trois rôles séparés répond à la plupart des questions que les gens apportent à cette couche. Un numéro privé sur l’interface VPN est normal et attendu. Il ne dit rien sur le fait que le point de terminaison ait changé ou non votre sortie publique, et il ne décide pas à lui seul quelles destinations votre trafic atteint.

Ce que fait exactement IPCP

IPCP est le protocole de contrôle IPv4 pour PPP. Chaque côté envoie des messages Configure-Request décrivant les options qu’il veut, et l’option d’adresse en fait partie. Un client qui n’a pas encore d’adresse demande généralement avec 0.0.0.0, et le serveur répond par un Configure-Nak portant l’adresse qu’il veut voir utiliser par le client. Le client demande ensuite cette adresse, et la session monte avec une adresse locale et une adresse distante.

Cet échange est documenté dans les spécifications PPP et IPCP, et il explique un détail qui ressemble à un bug : l’adresse est choisie par le serveur selon sa propre politique, qui peut être un pool, un réglage par utilisateur ou une adresse liée à l’identité authentifiée. Quand le pool est épuisé, ou que la politique entre en conflit avec la demande, l’authentification peut réussir tandis que la négociation d’adresse échoue, et le client signale une connexion qui ne se stabilise jamais.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Une ligne du journal de pppd nommant une adresse locale et une adresse distante est la fin réussie de cette négociation. Son absence, à côté d’une authentification réussie, pointe vers l’étape d’adresse plutôt que vers les identifiants.

Pourquoi le LAN ne peut pas vous répondre

Une adresse de la plage du côté distant crée l’attente que les hôtes de ce LAN peuvent vous atteindre, et la plupart du temps ils ne peuvent pas, sauf si le serveur route l’adresse de votre session vers le tunnel. Être dans un pool est une affirmation sur l’attribution, pas sur la topologie. Le serveur de fichiers du bureau n’a aucune route vers l’adresse de votre session sauf si le serveur VPN la transmet, et ce n’est peut-être même pas autorisé s’il le fait.

C’est aussi pourquoi les plages qui se chevauchent causent des problèmes hors de proportion avec leur taille apparente. Si le pool chevauche un LAN que le client utilise déjà, la table de routage du client a maintenant deux revendications sur le même préfixe, et la mauvaise l’emporte souvent pour des raisons sans rapport avec le tunnel.

Vérifiez la session, puis la route

Vérifiez d’abord l’interface, puis les routes, puis une destination qui compte. Chaque étape a son propre mode de défaillance, et tester les trois à la fois produit une conclusion que vous ne pourrez pas défendre plus tard.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Si le contrôle public montre l’adresse du point de terminaison alors qu’une destination privée expire, le tunnel porte votre route par défaut et le côté distant ne répond pas pour cette destination. Si la destination privée répond mais que le contrôle public ne change pas, le profil utilise le tunnel divisé et seule une partie du trafic passe par la session.

Gardez les trois étapes séparées

L’authentification, la négociation d’adresse et le transfert échouent différemment, et chacune a un responsable différent. Les identifiants sont un problème d’identité, l’épuisement d’IPCP est un problème de politique de serveur, et une route de retour manquante est un problème de conception de réseau. Signaler les trois comme « le VPN est cassé » garantit une correction lente.

Notez l’adresse attribuée, le pool d’où elle vient et si le LAN est censé l’atteindre. Cette seule note empêche la personne suivante de supposer un bail DHCP et de chercher une étendue qui n’a jamais été impliquée.