Le VPN se connecte mais les appareils du LAN sont inaccessibles : que vérifier

Le trafic entre dans le tunnel, la passerelle répond sur sa propre adresse et rien derrière elle ne répond. Ce schéma est courant et il n’est pas contradictoire : une réponse de la passerelle prouve que le tunnel s’est terminé, et elle ne prouve rien sur ce qui arrive à un paquet adressé au-delà. Les deux tests empruntent des chemins de code différents sur la même machine.

Testez désormais quelque chose de l’autre côté de la passerelle. L’adresse propre de la passerelle continuera de répondre, aussi cassé que soit le transfert.

La passerelle répond depuis sa propre pile

Un paquet adressé à la passerelle est remis à son chemin d’entrée local, où le noyau décide si une socket en écoute l’accepte. Un paquet adressé à un hôte derrière la passerelle est remis à la place au chemin de transfert, où un autre ensemble de contrôles s’applique. Le transfert peut être entièrement désactivé, ou être activé par le noyau puis rejeté par une règle de filtre qui ne mentionne jamais le tunnel. Rien de tout cela n’affecte la réponse propre de la passerelle, et c’est pourquoi le symptôme trompe si fiablement.

Les pages d’administration atteintes par le tunnel appartiennent aussi à la première catégorie. Elles sont une preuve concernant le tunnel, pas le réseau derrière lui.

Suivez le flux jusqu’à la première frontière qui le rejette

Partez du client et confirmez la route et l’adresse source que le flux utilisera. Observez ensuite la passerelle pour l’arrivée de ce flux exact, puis de nouveau pour le même flux qui sort vers le LAN. S’il n’arrive jamais, le problème vient du côté client ou des préfixes autorisés du tunnel. S’il arrive et ne sort jamais, le problème vient du transfert ou d’un filtre sur le chemin avant, et la capture a déjà dit lequel.

Exécuter le même test depuis la passerelle cache la moitié intéressante, car un paquet originaire de la passerelle a une autre source et une autre exigence de retour. Utilisez le flux du client, porteur de sa propre adresse source, à chaque étape. Une capture prise sur la mauvaise interface produit d’assurdes bêtises.

Les routes de retour et les pare-feu des hôtes échouent séparément

Une fois le paquet arrivé à l’hôte, trois autres choses doivent tenir. Le service doit écouter sur l’adresse à laquelle le paquet a été envoyé, le pare-feu de l’hôte doit l’accepter, et la réponse doit avoir une route de retour vers le pool de clients. La dernière échoue souvent, car la route par défaut de l’hôte pointe vers un routeur qui n’a jamais entendu parler de la plage du tunnel. Le résultat est une connexion qui s’établit du point de vue de l’hôte et meurt silencieusement dans l’autre direction.

Testez délibérément le chemin de retour en envoyant depuis le client et en surveillant le retour. Une capture unidirectionnelle règle en secondes ce qu’une heure de spéculation ne réglera pas.

Confirmez chaque saut avec l’adresse source du client

Exécutez les contrôles dans l’ordre et conservez chaque sortie, car la valeur tient à la comparaison et non à une ligne isolée. Les commandes ci-dessous figent l’adresse source, montrent la route choisie et capturent les deux côtés du transfert. Remplacez l’hôte LAN et l’interface de tunnel par les vôtres.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

La requête de route indique si le client enverrait seulement ce paquet dans le tunnel, et le ping indique si quelque chose est revenu de l’hôte. Comparer les deux captures sépare l’arrivée de la sortie, car une trame sur l’interface du tunnel sans contrepartie sur l’interface LAN est une décision de transfert et non une panne de service. Quand les deux captures montrent la requête et qu’une seule montre la réponse, la route de retour est le suspect restant.

Notez quelle adresse a répondu et quelle destination transférée a échoué. Cette phrase rend le rapport exploitable au lieu d’affirmer que le serveur est injoignable.