Coupe-circuit ou accès au LAN ? Deux réponses pour WireGuard

La poignée de main aboutit, la navigation fonctionne, et l’imprimante, le NAS et les hôtes SSH locaux disparaissent. Sur le client Windows, ce n’est généralement pas du tout une panne de routage : un pair dont les préfixes autorisés contiennent la valeur par défaut littérale active Bloquer le trafic non tunnelisé, et cette option est implémentée sous forme de règles de pare-feu qui suppriment les paquets sortant par toute autre interface. La table de routage liste toujours le sous-réseau local comme lien direct, et c’est pourquoi le symptôme semble être un mensonge. Trois conditions décident de ce qu’il faut faire, et une seule concerne le routage.

Deux pannes portent le même symptôme

La première panne est le mode de fermeture de sécurité du client, et sa signature est que tout ce qui est hors du tunnel s’arrête alors que le tunnel lui-même fonctionne parfaitement. La seconde est un véritable problème d’accessibilité : une route manquante, une entrée manquante sur le serveur pour un sous-réseau derrière le client, ou deux réseaux qui partagent la même plage d’adresses. Les deux produisent une machine qui peut naviguer et ne peut pas imprimer, et leurs correctifs sont opposés, donc le diagnostic doit venir avant la configuration.

L’observation décisive est de savoir si le sous-réseau local est encore présent dans la table de routage alors que le trafic vers celui-ci est supprimé.

Trois conditions décident de la réponse

Premièrement, cette machine a-t-elle besoin de la fermeture de sécurité ? Si la réponse est oui, un tunnel qui tombe doit arrêter le trafic plutôt que de le laisser revenir sur l’interface physique, et cette exigence passe avant le confort local. Deuxièmement, les appareils locaux doivent-ils rester accessibles tant que le tunnel est actif ? L’impression, le stockage réseau et les consoles de gestion locales en sont les raisons habituelles, et ce sont des exigences légitimes, pas des exceptions dont il faut s’excuser. Troisièmement, le profil exprime-t-il la valeur par défaut comme le littéral 0.0.0.0/0 ? C’est précisément ce détail qui déclenche les règles du client, et il est modifiable.

Répondez à ces trois questions par écrit avant de toucher à un profil, car chaque réponse renvoie à une configuration différente.

Choisissez la fermeture de sécurité et renoncez au LAN

Si les fuites comptent plus que l’accessibilité locale, conservez la valeur par défaut littérale et laissez Bloquer le trafic non tunnelisé activé. C’est une position cohérente : la machine est traitée comme un appareil qui est soit dans le tunnel, soit hors ligne, et les services locaux sont atteints depuis un autre appareil ou via le tunnel si le serveur les route. Le coût est réel et devrait figurer dans les notes de déploiement, plutôt que d’être découvert par la personne qui a besoin d’imprimer.

C’est le bon choix pour les machines qui traitent un travail qui ne doit pas apparaître sur un réseau de café lorsque le tunnel tombe. C’est une mauvaise valeur par défaut pour un ordinateur portable domestique qui a aussi besoin du scanner.

Choisissez l’accès au LAN et exprimez la valeur par défaut autrement

Si les appareils locaux doivent rester accessibles, exprimez la même couverture sans le préfixe par défaut littéral. Deux demi-préfixes couvrent toutes les adresses IPv4, la paire équivalente couvre IPv6, et le client n’insère plus les règles de blocage car la chaîne qu’il recherche est absente.

[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820

Décocher cette case amène le client à écrire les deux mêmes paires dans le profil, donc comparer le fichier généré au bloc ci-dessus est un moyen rapide de confirmer le mécanisme plutôt que de le deviner. Deux conséquences s’ensuivent. La couverture est identique, donc rien d’autre au tunnel ne change. La protection n’est pas identique : les règles disparues, un tunnel qui tombe laisse la machine utiliser son interface physique, et c’est précisément ce que la fermeture de sécurité empêchait.

Vérifiez les deux autres suspects dans tous les cas

Une fois la question du pare-feu réglée, confirmez que le sous-réseau local est réellement routé et que l’extrémité distante connaît tout ce qui se trouve derrière ce client. Un serveur qui doit atteindre un LAN derrière un client a besoin de ce préfixe dans la liste autorisée du client sur le concentrateur ; omettez-le et le concentrateur ne peut pas choisir de pair pour ces adresses, et aucune configuration client n’en crée un.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0

La catégorie de réseau compte plus qu’on ne le pense : un adaptateur de tunnel nouvellement créé classé comme public change les règles qui s’y appliquent, et le résultat peut ressembler à un blocage du pare-feu à l’extrémité distante. L’impression des routes montre si une valeur par défaut existe du tout, ce qui sépare un problème de politique d’une route manquante.

Testez ensuite trois choses en une seule séance : internet, un hôte local par adresse et un hôte à travers le tunnel. La poignée de main ne prouve que la concordance des clés, donc ce sont les trois tests qui démontrent la politique. Si l’hôte local refuse encore une fois l’option décochée, les suspects restants sont la route, la liste autorisée de l’extrémité distante et le sous-réseau en double, dans cet ordre.