Pourquoi l'administration du routeur cesse de répondre après un changement de VPN

Vous avez modifié une route ou une règle de pare-feu pour tester un tunnel sur le routeur, et maintenant la page d'administration ne répond plus depuis l'ordinateur portable qui fonctionnait bien il y a dix minutes. Le réflexe est de blâmer le VPN. La plupart du temps, le tunnel est sain et l'une de trois autres choses a lâché : aucune route de retour vers l'adresse propre du routeur, une politique d'entrée qui rejette la requête, ou un service web qui n'écoute pas sur l'adresse que vous appelez. Les trois se ressemblent dans le navigateur, c'est pourquoi les gens redémarrent le tunnel pendant une heure et n'apprennent rien.

Voici le mythe qu'il vaut la peine de tuer d'abord : un tunnel qui fonctionne n'est pas un moyen de rentrer. C'est un nouvel attachement réseau avec ses propres questions de confiance, et il peut supprimer discrètement votre ancien chemin d'administration tout en en ouvrant un nouveau que personne n'a examiné.

Le tunnel n'a jamais été le chemin d'administration

Le transfert et l'entrée sont deux métiers différents. « Un client peut-il atteindre le NAS à travers le tunnel ? » est une question de transfert sur des paquets qui traversent le routeur. « Puis-je ouvrir le port SSH du routeur ? » est une question d'entrée sur des paquets adressés au routeur lui-même. Une règle d'autorisation écrite pour du trafic transféré ne fait rien pour la seconde, et c'est la raison la plus fréquente pour laquelle un tunnel qui transporte parfaitement le trafic refuse quand même votre session d'administration.

L'erreur inverse est de faire confiance à un nom d'interface. Un tunnel est chiffré vers le pair, pas vers chaque service derrière lui, et le mot VPN dans une étiquette d'interface ne dit rien sur les sources qui devraient avoir le droit de se connecter.

Premier niveau : existe-t-il une route vers l'adresse propre du routeur ?

Partez du client et demandez au noyau où ira le paquet. Sous Linux, ip route get 10.6.0.1 affiche la route choisie, l'interface de sortie et l'adresse source. S'il indique la route par défaut vers votre fournisseur, le paquet n'entre jamais dans le tunnel, et aucune règle sur le routeur ne peut le sauver.

Le côté tunnel a sa propre version de la question. WireGuard traite AllowedIPs comme une table de routage par clé cryptographique : à chaque extrémité, elle déclare quelles adresses source un pair peut utiliser et quelles destinations sont envoyées à ce pair. Si l'entrée du client n'inclut pas l'adresse tunnel du routeur, le client n'a pas de route vers elle. Si l'entrée du serveur pour ce client ne couvre pas l'adresse tunnel du client, le serveur jette le paquet avant même de consulter une règle de pare-feu.

Confirmez l'adresse exacte que vous comptez atteindre avant de déboguer la politique. Un enregistrement DNS obsolète ou une entrée de voisin en cache d'avant le changement vous envoie vers une adresse que le routeur n'a jamais possédée.

Deuxième niveau : la politique d'entrée, pas la politique de transfert

Les pare-feu évaluent les règles sur l'interface où le paquet arrive. Sur pfSense et OPNsense, l'onglet d'interface et l'ordre des règles décident si le trafic vers les services propres du pare-feu est autorisé ; une règle qui laisse sortir les clients LAN vers internet n'est pas une règle qui autorise un pair du tunnel à ouvrir l'interface web. Sur OpenWrt avec firewall4, chaque zone porte une politique d'entrée, option input 'ACCEPT' ou 'REJECT', et une interface de tunnel dans une zone dont l'entrée est REJECT refusera les connexions d'administration tout en transférant encore le trafic si le transfert est autorisé.

Ne désactivez pas la règle anti-verrouillage pour faire fonctionner le nouveau chemin. Cette règle empêche une mauvaise règle de verrouiller l'adresse d'administration LAN ; elle protège le sous-réseau LAN, pas le sous-réseau du tunnel que vous venez de créer. Ajoutez une règle étroite pour la source de l'administrateur et laissez le filet de sécurité tranquille. La documentation pfSense sur l'accès administrateur explique où se trouvent ces contrôles.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Troisième niveau : quelque chose écoute-t-il sur cette adresse ?

Un service peut tourner et rester inatteignable parce qu'il s'est lié à une seule adresse. L'uhttpd d'OpenWrt garde des entrées d'écoute explicites dans /etc/config/uhttpd, par exemple list listen_http '0.0.0.0:80' ; une compilation qui ne se lie qu'à l'adresse LAN n'accepte rien sur l'adresse du tunnel, et les produits qui exposent un réglage d'interface d'écoute se comportent de la même façon. Les commandes d'écoute ci-dessus répondent directement à cela.

Séparez ensuite le refus du silence. nc -vz 10.6.0.1 443 qui renvoie une connexion refusée signifie que le paquet a atteint le routeur et que quelque chose l'a rejeté, soit un port fermé, soit une règle de rejet explicite. Un blocage jusqu'au délai d'attente signifie que le paquet a été jeté ou n'a jamais été routé. Cette distinction vous dit quel niveau inspecter ensuite, et elle coûte cinq secondes.

Une interface VPN est une frontière, pas un chemin de récupération

Le chiffrement protège le câble ; il ne dit rien sur qui peut ouvrir la page d'administration. Une fois le tunnel opérationnel, résistez à l'envie de résoudre l'accessibilité en autorisant tout sur l'interface du tunnel. Donnez aux administrateurs une règle liée à leur propre adresse de tunnel ou un tunnel séparé réservé aux administrateurs, et tenez les utilisateurs ordinaires, le NAS, les caméras et les portables de la famille loin du port d'administration. Un pair qui a besoin d'un partage de fichiers ne devrait pas être à une règle de la connexion au routeur.

Le rôle du routeur change la réponse. Un routeur qui termine le tunnel peut légitimement accepter des administrateurs depuis celui-ci, tandis qu'un routeur qui n'utilise le tunnel que comme sortie internet ne devrait généralement pas. Dans les deux cas, l'autorisation de sous-réseau n'est pas la connexion, alors gardez l'authentification des comptes et la sécurité du transport activées.

Le geste compensatoire que les gens font après un verrouillage est pire : activer l'administration par WAN ou rediriger un port vers l'interface web. Cela transforme une courte panne en exposition permanente, et la page de connexion est alors accessible à tous les scanners d'internet. Testez aussi le côté refusé, pas seulement le côté autorisé, pour qu'un pair qui ne devrait pas avoir d'accès administrateur expire ou soit refusé au lieu de recevoir une invite de connexion.

Testez aussi avec une connexion fraîche. Un pare-feu à états conserve les flux existants dans sa table d'états, si bien que la session SSH déjà ouverte peut survivre à un changement qui bloque toute nouvelle connexion. C'est ainsi qu'un verrouillage reste invisible jusqu'au prochain redémarrage ou à la prochaine mise en veille de l'ordinateur portable.

Préparez le chemin de retour avant de toucher à la politique

Notez quatre choses avant le premier changement : comment vous atteindrez l'appareil si le tunnel meurt, par exemple une console série, une console du fournisseur ou une machine sur le LAN ; où la configuration actuelle est exportée ; quelle règle ou route unique vous êtes sur le point de modifier ; et comment vous annulerez exactement cet élément. Sur OpenWrt, sysupgrade -b /tmp/backup.tar.gz capture la configuration, et les modifications restent en attente jusqu'à uci commit, ce qui vous donne une annulation bon marché si vous vous en apercevez à temps. pfSense tient un historique de configuration, et AutoConfigBackup n'aide que s'il était déjà activé. Si le routeur applique un jeu de règles fail-closed, vérifiez que le chemin de maintenance prévu n'est pas dans le trafic que cette règle bloque, et rappelez-vous qu'un redémarrage réapplique les règles persistantes au lieu de les effacer.

Changez une frontière par tentative, puis testez depuis une nouvelle connexion plutôt que depuis le shell que vous gardez ouvert. Si le test échoue, annulez ce seul changement avant de toucher au niveau suivant. Le tunnel peut rester debout tout le temps, mais son icône d'état verte ne prouve pas que vous pouvez encore entrer.

Vérification rapide avant de partir :

• Pouvez-vous atteindre le routeur depuis une source qui ne dépend pas de la règle que vous venez de modifier ?
• La politique d'entrée sur l'interface du tunnel n'autorise-t-elle que la source de l'administrateur ?
• Le service d'administration est-il lié à une adresse qui existe sur le tunnel ?
• Avez-vous testé un pair refusé et une session fraîche ?
• La surface d'administration par WAN est-elle toujours fermée ?