Le client VPN routé atteint le serveur mais pas les hôtes du LAN

Le tunnel monte, le client envoie un ping au serveur VPN, et un partage sur une machine à un saut de là ne répond jamais. Rien dans la configuration du client ne l’explique, car la requête a bien quitté le client et est bien arrivée. Ce qui a échoué, c’est le trajet retour, et l’appareil qui a échoué est généralement la passerelle du LAN et non l’hôte VPN. Tracer le paquet de réponse explique toute cette classe de symptômes.

Suivez la réponse, pas la requête

Le serveur VPN déchiffre le paquet du client et le transfère vers le LAN en laissant l’adresse du client dans le champ source. L’hôte de destination répond à cette adresse, et désormais sa propre table de routage décide de tout. Sa passerelle par défaut ne sait rien du pool du tunnel, donc la réponse part vers le fournisseur d’accès et est jetée quelque part sur ce chemin.

Chez le client, le symptôme est un délai silencieux : aucun refus, aucune réinitialisation, juste rien. La navigation dans un partage se bloque, le ping signale l’absence de réponse, et les journaux du serveur semblent sains parce que le serveur a fait son travail.

Placez la route de retour là où les hôtes regardent

Chaque hôte du LAN consulte sa passerelle par défaut, donc la passerelle est le seul appareil qui doit savoir où se trouve le pool du tunnel. Ajoutez-y une route statique et chaque hôte hérite du bon chemin sans être touché.

Si la passerelle distribue sa propre adresse comme option DHCP, diffusez la route de cette façon pour que les nouvelles machines la reprennent automatiquement. Sinon, la route vit dans un fichier de configuration et disparaît à la prochaine reconstruction.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Pourquoi le NAT source semble réparer les choses

Masquer le pool de clients derrière l’adresse du serveur VPN supprime le problème en retirant l’adresse du client du paquet. Les réponses reviennent alors au serveur, qui sait déjà comment atteindre le tunnel, et tout fonctionne. Le prix à payer est que les hôtes internes ne voient plus qui est le client, et que chaque connexion semble provenir d’une seule machine.

Cet échange est parfois correct, par exemple lorsqu’un appareil d’un fournisseur ne peut pas recevoir de route statique. Ne rendez pas la règle plus large que le pool actuel, car une règle écrite pour un /24 cesse de correspondre le jour où le pool est renuméroté en /16, et le premier signe est une vague de nouveaux clients qui se connectent et n’atteignent rien.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Le chemin dans le cloud exige trois réglages

Dans un VPC, le même manque revient sous une autre forme, car le sous-réseau n’a aucune route pour la plage des clients. La table de routage a besoin d’une entrée pour le pool du tunnel qui cible l’interface réseau de l’instance, et l’interface doit avoir la vérification de source et de destination désactivée pour que la plateforme accepte des paquets dont la source n’est pas sa propre adresse. Les groupes de sécurité et les ACL réseau doivent aussi admettre le pool dans les deux sens.

Chaque omission produit une défaillance partielle distincte. Omettez l’entrée de la table de routage et les instances privées répondent dans un sous-réseau qui ne peut pas rapporter la réponse au pool. La vérification restant active, la plateforme jette la réponse après que l’instance l’a déjà envoyée. Sans la règle du groupe de sécurité, la requête elle-même n’arrive jamais, et le client voit le délai une couche plus tôt.

Exécutez les vérifications dans cet ordre

Confirmez le transfert et la politique de filtrage avant d’accuser le routage, car un hôte qui ne transférera pas échoue de la même manière silencieuse. Lisez ensuite le réglage effectif du chemin inverse sur l’interface qui porte le tunnel, car un filtre strict peut jeter des réponses arrivant d’une direction inattendue.

Terminez par une capture prise sur l’hôte du LAN pendant que le client le ping. Une requête qui arrive sans réponse correspondante prouve le chemin retour, et une requête qui n’arrive jamais renvoie la faute au serveur ou au tunnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

La vérification de source et de destination est documentée dans le guide de l’interface réseau élastique. Réglez-la sur l’interface qui porte réellement le trafic du tunnel, pas sur un adaptateur sans rapport attaché à la même instance.