Serveur VPN domestique ou serveur cloud : lequel atteint votre NAS ?
Le tunnel monte, mais le NAS de la maison reste injoignable. Choisissez l’emplacement de l’extrémité selon la ressource à atteindre, puis vérifiez la route.
Le tunnel monte, le client affiche un point vert, et ssh 192.168.1.20 reste bloqué jusqu’au délai d’expiration. J’ai vécu exactement cela après avoir loué une petite instance cloud et y avoir installé WireGuard : poignée de main correcte, DNS correct, et le NAS de mon bureau aussi injoignable que s’il était sur la lune. Le tunnel n’avait rien de défectueux. L’extrémité était parquée dans un réseau sans route vers ma maison. L’emplacement de l’extrémité décide quels réseaux sont adjacents, alors choisissez-la selon la ressource à atteindre d’abord et comparez l’hébergement ensuite.
Un tunnel n’atteint que les réseaux que l’extrémité peut router
Un VPN remet à votre client une adresse dans le domaine de routage de l’extrémité. Quand le client envoie un paquet à 192.168.1.20, l’extrémité doit savoir où il va. La table d’une VM cloud connaît les sous-réseaux VPC du fournisseur ; elle n’a jamais entendu parler de votre LAN. Connecté et joignable sont deux faits différents, et l’essentiel de la confusion maison-cloud vient de prendre le premier pour une preuve du second.
Une commande tranche. Sur l’extrémité, ip route get 192.168.1.20 nomme soit une interface LAN, soit la route par défaut. Sur une machine domestique, la réponse est le côté LAN. Sur une instance cloud, le paquet part vers internet et meurt. Activer net.ipv4.ip_forward=1 et ajouter une règle MASQUERADE n’y change rien, car il n’y a rien à transmettre tant que quelque chose côté maison ne termine pas un lien vers le cloud.
Le cas domestique a une seconde moitié : le chemin de retour. Les paquets qui quittent le LAN par la machine du tunnel passent par NAT, ou le LAN a besoin d’une route statique vers le sous-réseau du tunnel. Quand un seul sens fonctionne, vérifiez sysctl net.ipv4.conf.all.rp_filter. Le filtrage strict du chemin inverse rejette les réponses arrivant sur une interface différente de celle que prédit la route, et le symptôme ressemble exactement à une règle de pare-feu.
Lisez le symptôme avant de toucher à la configuration
Le tunnel ne s’établit pas : clés, adresse de l’extrémité ou port UDP bloqué. Tunnel monté mais hôtes du LAN morts : emplacement et routage. Tunnel monté mais navigation morte : transfert, NAT ou DNS. Ce sont trois couches et trois vérifications différentes, et réécrire une configuration déjà correcte gâche une soirée.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
L’accessibilité entrante de la maison mérite sa propre vérification, car elle décide si l’hébergement à domicile est seulement possible. Comparez l’adresse WAN annoncée par votre routeur à celle que voit un hôte extérieur. Si elle tombe dans 100.64.0.0/10, ou si les deux ne concordent pas, vous êtes derrière un NAT d’opérateur et aucune redirection de port ne fonctionnera jamais. Les vraies options sont un relais, un lien cloud qui appelle vers l’extérieur depuis la maison, ou déplacer l’extrémité.
Ce que l’hébergement à domicile apporte, et ce qu’il coûte
La maison est le seul emplacement situé dans le LAN par défaut, et c’est toute la raison d’y mettre un serveur. Les appareils qui ne répondent que sur le segment local, comme les imprimantes et les pages d’administration du NAS qui refusent les sous-réseaux non locaux, fonctionnent sans routage supplémentaire. Vous exploitez aussi vous-même la machine, le routeur et la liaison.
Les coûts sont physiques. L’upload domestique est le plafond pour tous les clients à la fois, donc un appel vidéo et une sauvegarde se disputent le même tuyau. Électricité, usure du disque, correctifs, une adresse dynamique qui exige DDNS, un routeur qui doit transférer l’UDP vers l’intérieur et parfois un double NAT : tout retombe sur vous. Ce que les gens oublient, c’est la reprise : si la machine meurt pendant votre absence, votre seul chemin vers la maison meurt avec elle. Gardez un second appareil avec les mêmes clés, ou au moins un plan d’accès physique.
Si vous voulez l’accès au LAN sans la machine à la maison, construisez un lien au lieu de faire semblant. L’extrémité cloud devient un routeur : un tunnel depuis le côté maison avec AllowedIPs = 192.168.1.0/24 sur le peer cloud, plus transfert et NAT sur la machine cloud. Le guide de transfert de strongSwan parcourt la moitié retour de cette configuration, et c’est là que la plupart de ces tentatives échouent. Le peer domestique doit désormais être monté pour que quoi que ce soit fonctionne, vous avez donc échangé une dépendance contre une autre et devriez l’écrire.
À quoi sert réellement une extrémité cloud
Une extrémité cloud change votre sortie publique. Le trafic part de la plage d’adresses du fournisseur, et les sites voient cette adresse plutôt que celle de la maison. C’est la valeur, et c’est aussi pourquoi un VPN cloud ne vous donne pas le NAS : vous avez déplacé la sortie, pas le LAN.
Vous exploitez toujours le système invité, le service VPN et ses identifiants pendant que le fournisseur exploite l’hyperviseur et le réseau physique, et ce partage compte quand quelque chose casse à 2 heures du matin. Une extrémité publique est scannée en continu, alors gardez le port de gestion fermé, n’autorisez que le port VPN et corrigez selon un calendrier. Les groupes de sécurité et les pare-feu du fournisseur doivent autoriser ce port, et certains clouds rejettent le trafic transféré tant que vous n’ajustez pas la vérification source et destination sur l’instance.
Une petite instance couvre une poignée de clients, mais le chiffrement est du travail CPU, et une instance burstable à court de crédits se comporte irrégulièrement sous charge soutenue. Regardez le chemin que vous utilisez vraiment, pas la fiche technique.
Une décision que vous pouvez écrire
La tâche décide de l’emplacement, pas l’étiquette sur la machine. Si vous avez besoin d’un appareil sur votre LAN domestique, la réponse correcte la moins chère est une extrémité à la maison ; une machine cloud ne fonctionne qu’après avoir construit le lien retour. Si vous avez besoin d’une autre sortie publique, la réponse est le cloud et la question du LAN ne se pose jamais. Vouloir les deux est légitime, mais cela signifie deux extrémités, deux jeux de clés et deux routes documentées.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
Vérifiez depuis le client dans l’ordre : poignée de main, adresse du peer, un hôte du LAN, puis l’IP de sortie. curl -s https://ifconfig.me montre ce que voit internet, et ip route get 192.168.1.20 montre ce que croit l’extrémité. Quand le contrôle de sortie passe et que celui du NAS bloque, vous avez déjà la réponse sur l’emplacement ; ajuster AllowedIPs sur le client ne fera pas apparaître de route. Une ligne divisée comme 10.8.0.0/24, 192.168.1.0/24 ne garde le trafic du LAN dans le tunnel que lorsque cette route existe vraiment.