Atteindre la page d’administration du routeur par VPN, pas par le WAN
Un VPN à sortie publique ne crée pas de chemin de retour vers votre LAN. Terminez le tunnel sur une passerelle qui atteint le routeur, puis limitez qui peut ouvrir la page d’administration.
La page d’administration du routeur s’ouvre en deux secondes depuis le canapé et expire depuis une chambre d’hôtel, alors que le client VPN signale une connexion permanente. Ce que vous avez, c’est une voie de sortie, pas une voie de retour : le tunnel transporte votre trafic vers internet et s’arrête là. Atteindre un appareil à l’intérieur de votre propre LAN exige une session qui se termine sur quelque chose ayant une route vers lui. C’est une décision de conception, pas un réglage, et elle détermine si le reste du travail est possible.
La distinction se perd facilement parce qu’un seul produit peut faire les deux. Un client de sortie commercial et un serveur d’accès distant peuvent parler le même protocole sur le même port, et la différence est de quel côté appartient l’espace d’adressage derrière le point de terminaison.
Quel côté du tunnel possède le LAN
Pour l’administration, le point de terminaison doit se trouver dans le réseau que vous voulez atteindre, ou disposer d’un chemin autorisé vers lui. Un routeur qui exécute son propre serveur VPN remplit la condition ; un petit hôte toujours allumé avec une adresse fixe et une route vers le LAN aussi. Un service de sortie exploité par un tiers ne la remplit pas, car son point de terminaison n’a ni interface sur votre LAN ni règle qui permettrait à une interface d’apparaître. C’est la vérification à terminer avant de toucher quoi que ce soit d’autre.
Le micrologiciel étiquette rarement cette différence, alors lisez ce que fait la fonction plutôt que le protocole qu’elle nomme. WireGuard, OpenVPN et IKEv2 apparaissent des deux côtés du marché : une version envoie le trafic domestique vers l’extérieur, une autre accepte votre appareil distant. Une version client uniquement ne peut pas devenir serveur par configuration, quelle que soit la formulation du menu.
Faire exister la route de retour
Un serveur WireGuard sur le routeur a une adresse d’interface comme 10.8.0.1/24 et une entrée de pair pour l’ordinateur portable. Le client décide quelles destinations il envoie dans le tunnel, et une liste ne contenant que le sous-réseau du tunnel laisse le LAN invisible, quelle que soit la configuration du serveur. Les deux extrémités doivent s’accorder, et une seule est généralement modifiée.
wg show wg0 allowed-ips
ip route get 192.168.1.1
La première commande indique ce que chaque pair est autorisé à envoyer du point de vue du serveur ; la seconde indique où irait réellement une adresse du LAN sur le client. Une destination du LAN qui se résout vers l’interface du tunnel est un routage qui fonctionne, et celle qui sort par la passerelle physique n’arrivera jamais, quoi que dise le pare-feu. Ajoutez le préfixe du LAN à la liste autorisée du client et les deux mêmes commandes deviennent une étape de vérification plutôt qu’un diagnostic.
Le même saut pour les passerelles IPsec est décrit par la documentation de transfert de strongSwan, où le transfert et une règle de NAT source relient un client de tunnel à un hôte interne. L’adressage diffère ; l’exigence non.
Qui peut ouvrir la page d’administration
Le contrôle d’accès appartient au routeur, pas à l’intention d’être prudent. N’autorisez que l’identité de tunnel authentifiée ou la plage source qui a besoin de la page, et lisez la chaîne d’entrée du routeur ainsi que toute politique de LAN transférée. Une règle qui laisse le LAN filaire atteindre la page d’administration ne dit rien d’un client arrivant sur l’interface du tunnel. Écrivez l’exception pour une identité précise, puis gardez une seconde identité qui doit être refusée.
L’écouteur est l’autre moitié et il est invisible dans la sortie du pare-feu. ss -ltnp montre l’adresse à laquelle le serveur web est lié, et un service lié à la seule adresse du LAN ne répondra pas sur l’adresse du tunnel, quelles que soient les règles permissives. Le relier ailleurs ou ajouter une adresse est un changement de configuration sur le routeur, pas un changement de pare-feu.
Gardez l’authentification et la validation du transport activées dans la même passe. Atteignable n’est pas digne de confiance, et chaque appareil à l’intérieur d’un tunnel ne devient pas administrateur pour autant. Les identifiants du tunnel et le compte du routeur sont des privilèges séparés avec des cycles de vie séparés, si bien que la clé d’un ordinateur portable perdu peut être révoquée sans réinitialiser le mot de passe de chaque administrateur.
Tester depuis l’extérieur, pas depuis le canapé
Testez depuis un réseau que vous ne contrôlez pas. Connectez-vous par le tunnel approuvé, ouvrez une nouvelle session d’administration et modifiez quelque chose d’inoffensif que vous voyez se refléter sur la page. Depuis le canapé, vous prouvez que le LAN fonctionne, ce qui n’a jamais fait de doute.
Testez ensuite les refus avec le même soin. Essayez la page sans le tunnel et confirmez qu’elle échoue, et confirmez que le service d’administration n’écoute pas du tout sur l’adresse WAN. Une page simplement non liée n’est pas un contrôle d’accès, et un écouteur sur le WAN affichant un formulaire de connexion reste un écouteur sur le WAN. Si un mot de passe est la seule chose entre internet et la console du routeur, la conception est un mot de passe.
Les services domestiques méritent un coup d’œil pendant que vous y êtes. Le durcissement des règles de gestion casse souvent le réseau invité ou le résolveur utilisé par les appareils de la famille, et cela ressort des jours plus tard comme une plainte sans rapport.
Garder une voie de retour pendant que vous changez les choses
Avant de modifier des routes ou des réglages de tunnel à distance, préparez une voie de retour indépendante. Une session existante peut survivre au changement qui bloque déjà les nouvelles connexions, et c’est exactement ainsi que les gens s’enferment dehors en regardant une session qui fonctionne encore. Les options sont concrètes : un redémarrage planifié vers une configuration connue, un accès console ou physique, un second tunnel qui ne dépend pas du réglage en cours de modification, ou une gestion hors bande là où le matériel la propose. Choisissez-en une et prouvez-la avant la fenêtre de maintenance, pas pendant.
Gardez l’enregistrement court et à jour : quel hôte termine le tunnel, quelles identités peuvent atteindre la page, à quelle adresse le service se lie et comment un appareil perdu est révoqué. Cette liste sert aussi de plan de reprise, parce qu’elle dit où vit chaque dépendance. Une route de retour manquante est un problème de routage à réparer, et ce n’est jamais une raison de publier l’administration sur le WAN.