Tunnel actif, pas d’internet : où le transfert s’arrête

Le client se connecte, le tunnel transporte des pings vers la passerelle, et rien au-delà ne répond. Cet état est normal pour une passerelle qui n’a jamais eu pour but que de donner accès à des réseaux protégés, et c’est une panne pour une passerelle annoncée comme sortie tunnel complet. Avant de changer des règles, confirmez quel service a été promis. Suivez ensuite une seule requête publique dans les quatre endroits où elle peut s’arrêter. Une requête et une capture de paquets règlent plus qu’une page de suppositions.

Confirmez si la sortie internet a jamais été le dessein

Un profil de tunneling divisé n’achemine que les sous-réseaux protégés dans le VPN, si bien que la navigation publique continue par le lien local et ne touche jamais la passerelle. Un profil de tunnel complet installe une route par défaut dans le tunnel, ce qui rend la passerelle responsable de tout le trajet. Les deux sont des conceptions légitimes, et les confondre produit un rapport de panne là où il n’y en a pas. Lisez les routes annoncées par le client avant de tester quoi que ce soit d’autre, car la table de routage répond à la question que le ticket pose généralement mal.

Ce que le client installe n’est pas toujours ce que le profil prévoit. Une route poussée peut être annulée par une route locale de métrique plus faible, et un client qui garde sa route LAN tout en ajoutant une route par défaut se comporte comme un tunneling divisé pour ce sous-réseau.

Suivez une seule requête publique

Choisissez une seule destination et suivez-la depuis le client vers l’extérieur. Sur le client, vérifiez que le paquet choisit bien le tunnel et quelle adresse locale il utilise comme source. Vérifiez ensuite la passerelle : le paquet arrive-t-il, et sort-il par l’interface publique. Chacune de ces réponses élimine une catégorie entière de causes.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Si la passerelle ne voit jamais le paquet, la route du client ou le choix du tunnel est faux. S’il arrive et ne sort pas, le problème est sur la passerelle, et les trois contrôles restants s’appliquent.

Vérifiez le transfert, la route et la traduction

Le guide de transfert fourni avec strongSwan vaut pour une passerelle de tout type de tunnel : le noyau doit être autorisé à déplacer des paquets entre interfaces, et une route utilisable doit pointer vers internet. La politique du pare-feu doit ensuite autoriser le trafic, et l’adresse source doit être une adresse à laquelle le côté public peut répondre. Une adresse client privée transférée sans changement vers internet ne reçoit jamais de réponse.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

La traduction de source est la pièce manquante habituelle. Avec elle, la passerelle réécrit la source du client vers son adresse publique et suit le flux ; sans elle, la réponse n’a nulle part où aller. Les plateformes cloud ajoutent une seconde limite, où la table de routage ou le groupe de sécurité de l’instance peut abandonner du trafic que le pare-feu invité autorise. Cette limite est facile à manquer, car le système invité paraît correctement configuré de l’intérieur.

Le filtrage de chemin inverse sur une configuration asymétrique peut aussi rejeter des paquets valides. Lisez le compteur de cette règle au lieu de supposer qu’elle est correcte, car un réglage strict sur l’interface publique rejette le trafic qui arrive par un chemin différent de celui que prédit la table de routage.

Chemin de retour et résolveur sont deux réponses différentes

Surveillez aussi la réponse, pas seulement la requête. Si la requête part traduite et que la réponse revient dans le flux traduit, le transfert fonctionne même si l’application échoue encore, et l’enquête suivante relève de l’application ou du DNS.

Un site qui renvoie une erreur HTTP prouve que le transfert internet fonctionne. Un nom qui ne se résout pas alors que l’accès par adresse fonctionne est un problème de résolveur, pas de NAT.

Après une correction ciblée, retestez le client ainsi que toute ressource privée volontairement restreinte. Accorder l’accès à internet ne doit pas élargir discrètement l’accès à tous les réseaux rattachés à la passerelle.