L'état indique que le tunnel est monté, un navigateur sur le routeur lui-même charge des pages, et chaque appareil derrière lui expire encore. Cette combinaison réduit le problème à une couche que la plupart des guides VPN ne mentionnent jamais : le routeur n'est pas le seul hôte dont les paquets doivent survivre au tunnel. Le trafic généré localement et le trafic transféré empruntent des chemins différents à travers la même boîte. Testez depuis un client et la différence cesse d'être théorique.

Lire la panne depuis un hôte du LAN

Commencez par l'appareil qui échoue, car un diagnostic sur le routeur répond à une autre question. Vérifiez que la passerelle par défaut du client est ce routeur, notez son adresse source et son sous-réseau, puis regardez ce qui sort de l'interface tunnel du routeur.

Si l'adresse du client est traduite, le côté distant voit l'adresse du tunnel, et tout y paraît sain alors que le client échoue toujours. Si elle ne l'est pas, le côté distant doit connaître une route de retour vers le sous-réseau du client, et beaucoup de passerelles n'ont pas une telle route par défaut. Dans les deux cas, le succès du routeur lui-même n'a aucune importance, car ses paquets ont été générés localement et n'ont jamais emprunté le chemin de transfert.

Le trafic local et le trafic transféré sont différents

Linux et la plupart des firmwares de routeur traitent les paquets émis par la boîte elle-même différemment des paquets qui la traversent. La chaîne output voit les premiers, la chaîne forward voit les seconds, et une politique ajustée au trafic propre du routeur peut laisser le transfert intact.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Vérifiez si le transfert est activé, puis lisez la chaîne forward plutôt que la chaîne output. Une règle qui autorise la connexion extérieure chiffrée n'est pas une règle qui autorise le transfert de paquets déchiffrés, et confondre les deux produit exactement ce symptôme. Le tunnel monté ne prouve que la première.

Le chemin de retour doit aussi exister

La traduction de source décide si un chemin de retour est nécessaire. Avec le masquage sur l'interface tunnel, les réponses reviennent à l'adresse du tunnel et le routeur annule la traduction. Sans lui, la passerelle distante a besoin d'une route explicite vers le sous-réseau du client, et sa propre politique doit autoriser cette direction.

Notez lequel des deux modèles le déploiement utilise avant de changer quoi que ce soit, car les réparations pointent dans des directions opposées. Ajouter une traduction masque une route de retour manquante et casse les applications qui ont besoin de l'adresse source d'origine. Ajouter une route de retour sans traduction échoue silencieusement lorsque le pare-feu distant rejette la source inconnue. Choisissez-en un, documentez-le et faites correspondre l'autre côté.

Le DNS du client relève de la même revue. Le résolveur du routeur peut répondre alors qu'un client pointé vers un autre serveur n'obtient rien du tout.

Vérifiez un flux autorisé et un flux refusé

Après la correction, testez une nouvelle connexion depuis un client plutôt qu'une session de routeur existante. Confirmez ensuite qu'un segment qui ne doit pas utiliser le tunnel ne l'utilise toujours pas.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Vérifiez l'adresse source observée à l'extrémité distante, car elle indique quel modèle s'exécute réellement. Vérifiez aussi une résolution de nom en plus d'une adresse, car le comportement du résolveur est un chemin distinct à travers la même boîte.

Gardez les règles limitées aux réseaux de clients qui ont besoin du tunnel, et résistez à la tentation de désactiver le filtre de transfert pour faire passer un test. Ce changement répare le test et supprime la frontière que le tunnel était censé fournir. Écrivez l'adresse source, la décision de traduction et la route de retour dans une seule note, avec une date.

Articles similaires