Un tunnel WireGuard à domicile a besoin d'une route de retour depuis le LAN

L'accès au domicile est un service privé unique, pas une seconde sortie internet. WireGuard se termine sur une machine Linux derrière le routeur, le routeur conserve son rôle actuel, et le portable n'envoie que le préfixe du domicile dans le tunnel. Quel appareil transfère et lequel termine est la décision dont découle chaque règle ultérieure. Ratez ce partage et vous déboguerez un NAT que vous ne vouliez pas ajouter.

Décidez qui transfère et qui termine

Le routeur possède l'entrée publique : il accepte le paquet UDP et le transmet à l'hôte Linux. Cet hôte possède l'écouteur WireGuard et la décision de transfert vers le LAN. En pratique, le mappage envoie UDP 51820 vers 192.168.50.10, et le port propre de l'application reste fermé. Séparer les rôles garde le pare-feu court.

Écrivez le plan d'adressage avant de créer l'interface. Routeur 192.168.50.1, passerelle 192.168.50.10, service 192.168.50.20, tunnel 10.77.0.0/24 avec passerelle .1 et portable .2. La plage du tunnel ne doit pas chevaucher un réseau que le portable atteint déjà, sinon les destinations deviennent ambiguës. Un NAT d'opérateur ou un routeur en amont peut bloquer l'accès entrant, et aucune redirection de port locale n'y remédie.

Échangez les clés, puis dimensionnez les AllowedIPs

Créez une paire de clés distincte par extrémité et ne déplacez que les clés publiques par un canal vérifié. L'entrée peer de la passerelle n'autorise que la source tunnel du portable, car le LAN du domicile est derrière la passerelle et non derrière le portable. Mettre le LAN dans cette entrée décrit une topologie que vous n'avez pas construite.

[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64

[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32

AllowedIPs est le préfixe du domicile plus l'adresse tunnel de la passerelle, jamais 0.0.0.0/0, afin que la navigation ordinaire garde son chemin local. Gardez un seul propriétaire de la configuration et ne rattachez jamais la même interface à un second gestionnaire réseau.

La route de retour est la partie que les gens sautent

Cette conception conserve la source 10.77.0.2 du portable au lieu de la masquer en passerelle, donc les appareils du domicile doivent savoir comment y répondre. Ajoutez une route statique sur le routeur du domicile pour 10.77.0.0/24 avec 192.168.50.10 comme saut suivant, et lisez ce que wg-quick déduit des AllowedIPs dans sa référence. Sans cette route, une poignée de main terminée coexiste avec des réponses d'application qui n'arrivent jamais.

Si le routeur ne peut pas porter cette route, choisissez une conception de retour documentée. Ajouter discrètement du NAT change au contraire le modèle de source que vous venez d'écrire.

Autorisez un service, pas le sous-réseau

Activez le transfert IPv4 sur la passerelle et gardez trois devoirs de pare-feu séparés : admettre l'écouteur WireGuard, transférer la source du portable uniquement vers 192.168.50.20, et laisser le reste du réseau du domicile fermé à ce peer. Intégrez les règles au gestionnaire de pare-feu déjà utilisé au lieu de le vider. Une route pour tout le préfixe du domicile n'est pas une autorisation d'utiliser chaque appareil à l'intérieur.

L'authentification propre de l'application et le pare-feu de l'hôte sont une porte distincte. Nommez le service que le jeu de règles autorise, afin que le prochain relecteur puisse le confronter à la tâche prévue.

Testez depuis l'extérieur, puis retirez proprement

Montez les profils par leur propriétaire, confirmez la poignée de main, puis exercez l'application prévue depuis un réseau externe approuvé et vérifiez la réponse. Tentez un service du domicile qui doit rester refusé, car une règle permissive est invisible tant que rien ne l'utilise. Pour HTTPS, utilisez le nom du certificat et laissez la validation s'exécuter ; taper l'adresse brute et traverser l'avertissement ne prouve rien sur le chemin. PersistentKeepalive est facultatif : il aide un peer lié au NAT après une période d'inactivité, mais ce n'est ni une route manquante ni une correction de permission.

Une adresse publique dynamique nécessite des mises à jour DNS, et le portable doit résoudre à nouveau son extrémité après un changement ; de nouveaux enregistrements DNS ne déplacent pas une extrémité configurée. Retirez le portable en supprimant son peer de la configuration enregistrée et active ; supprimer le seul profil du portable ne révoque pas l'autorisation de la passerelle.