Serveur VPN domestique injoignable : remonter la chaîne NAT

Le serveur répond sur le LAN, la règle de redirection de port semble correcte, et pourtant un client extérieur ne peut pas se connecter. Franchir une frontière à la fois vers l'extérieur est plus rapide que modifier la règle une quatrième fois, parce que chaque frontière laisse sa propre preuve : la page WAN du routeur, la traduction du fournisseur et l'écouteur sur l'hôte. Partez de la page d'administration que vous avez déjà ouverte et terminez par un test depuis un réseau que vous ne contrôlez pas. Notez chaque résultat au fur et à mesure, car la séquence est le diagnostic et un nombre mémorisé n'est pas une preuve. Si vous n'avez besoin que d'un tunnel sortant, la traduction n'est pas votre problème : seul le trafic entrant non sollicité est bloqué.

Partez de la page WAN du routeur

Connectez-vous au routeur et lisez la page d'état plutôt que la liste des redirections de ports. Notez l'adresse WAN, l'interface à laquelle elle appartient et si le type de connexion est DHCP, PPPoE ou autre chose fourni par l'opérateur. Comparez ensuite cette adresse avec ce que rapporte un service externe, en utilisant un téléphone en données mobiles pour que l'observation ne repasse pas par le même routeur. Les deux nombres répondent à des questions différentes, et les comparer est tout l'objet de cette étape.

Une adresse WAN différente de l'adresse publique observée signifie qu'au moins un traducteur se trouve au-dessus du routeur. Ce n'est pas encore une panne, car beaucoup de fournisseurs traduisent par conception et le service fonctionne toujours. Si les deux concordent, le routeur possède probablement l'adresse et le problème s'est déplacé à l'intérieur de votre réseau. Dans tous les cas, notez le couple avec la date, car les fournisseurs réattribuent les adresses et une comparaison avec les notes du mois dernier ne vaut rien.

Remontez d'un saut

Lancez un traceroute depuis le routeur lui-même et lisez les premiers sauts. Des adresses publiques répétées, un premier saut qui répond avec une adresse privée ou une adresse dans la plage partagée 100.64.0.0/10 pointent tous vers un traducteur en amont. RFC 6598 définit cette plage précisément pour ce type de déploiement, et c'est pourquoi la voir dans le champ WAN est un signal fort et non une curiosité. Deux traducteurs sur le chemin rendent la trace moins évidente, alors lisez le motif plutôt qu'une seule ligne.

Certains fournisseurs n'affichent l'adresse attribuée que dans le portail client, alors regardez-y avant de conclure que le routeur ment. Une adresse du portail qui correspond à votre observation externe alors que le routeur annonce autre chose est la preuve la plus claire d'un traducteur en amont. Conservez les deux pages dans le journal des changements, car la discussion sur qui possède quelle frontière avance bien plus vite avec deux images datées.

Confirmez l'écouteur et la redirection

Un test sur le LAN prouve que le service fonctionne localement et ne prouve rien sur la joignabilité depuis l'extérieur. Beaucoup de routeurs répondent à leur propre règle de redirection depuis l'intérieur, si bien qu'un test en boucle réussit alors que le chemin externe est encore fermé. Confirmez que le démon est lié à l'adresse et au port que vous croyez qu'il utilise, puis testez depuis l'extérieur. Tout ce qui suit est en lecture seule.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Si le test externe montre qu'aucun paquet n'arrive au routeur, la chute a eu lieu en amont et aucune règle locale ne la corrigera. Si les paquets arrivent et que rien ne répond, la frontière suivante est l'écouteur ou le pare-feu de l'hôte. Une capture de paquets sur l'hôte tranche lequel des deux vous regardez, et cela prend moins de temps qu'un nouveau tour de devinettes sur les règles. Gardez l'écouteur et son transport inchangés pendant la comparaison, sinon le test suivant répondra à une autre question.

Changez la topologie, pas la même règle

Quand le traducteur appartient au fournisseur, le correctif est un autre chemin et non une redirection de plus. Un petit VPS avec une adresse publique, relié par un tunnel sortant depuis le côté maison, place un point d'extrémité joignable devant le service. Une adresse publique fournie par l'opérateur est plus simple là où elle existe et généralement moins chère que d'exploiter une machine. IPv6 supprime entièrement la traduction, à condition que le réseau client, les enregistrements DNS et la politique du pare-feu la prennent tous en charge.

DNS dynamique ne met à jour qu'un nom ; il ne crée pas de joignabilité, et le pointer vers une adresse partagée envoie les clients vers une passerelle du fournisseur que d'autres abonnés utilisent aussi. Cette panne ressemble exactement à un serveur mort, et c'est pourquoi la note des étapes précédentes compte. Notez vers quelle adresse le nom s'est résolu lorsque le test a échoué, et conservez la réponse avec le résultat du test.

Réécrivez le plan autour de la frontière que vous contrôlez : l'écouteur, le tunnel et les routes. Ne gardez l'ancienne redirection que tant qu'elle décrit encore quelque chose de vrai, car une règle qui ne correspond plus à la topologie est pire que pas de règle. Notez quelle couche bloquait réellement et quelle preuve l'a montré. Sinon, la prochaine personne qui ouvrira la page d'administration répétera chaque étape de cette marche depuis le début.