NordVPN sous Linux bloque le LAN : liste d’autorisation et DNS

Tout semble normal jusqu’à ce que vous tentiez d’atteindre quelque chose sur votre propre bureau. Le tunnel est monté, les pages se chargent et le lecteur réseau expire. Déconnectez-vous et le lecteur revient avant que vous ayez fini la phrase, ce qui vous dit plus que n’importe quel journal : le client refuse délibérément le trafic qui n’entre pas dans le tunnel, et votre réseau local est du mauvais côté de cette ligne.

Le coupe-circuit fait son travail

Un coupe-circuit existe pour empêcher le trafic de s’échapper quand le tunnel n’est pas disponible. Les plages d’adresses privées comptent comme du trafic qui n’entre pas dans le tunnel, donc une implémentation stricte les bloque avec tout le reste. Ce n’est pas un bug au sens où les gens l’entendent quand ils déposent le rapport.

Lisez d’abord le point de vue du client lui-même. Une commande imprime les réglages actuels, et une seconde montre les objets de pare-feu que le client a créés. Vous cherchez un drop ou un reject qui apparaît avant toute exception de tunnel, car c’est cet ordre qui rend le réseau local inaccessible.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Exécutez ensuite un test qui coupe le problème en deux. Atteignez l’appareil par adresse, puis par nom. L’adresse fonctionne et le nom échoue signifie que le pare-feu est innocent et le résolveur ne l’est pas. Les deux échouent signifie que le pare-feu refuse le paquet, et le reste de cet article s’applique.

Liste d’autorisation : choisissez le type d’entrée selon le symptôme

Le client propose une liste d’autorisation avec trois types d’entrée, et choisir le bon type, c’est l’essentiel du travail. Un sous-réseau couvre des hôtes. Un port couvre un service quelle que soit la destination. Un groupe multicast couvre le trafic de découverte, qui est une forme de trafic différente de tout ce qui est adressé à un hôte unique.

nordvpn allowlist add subnet 192.168.1.0/24
nordvpn allowlist add port 22
nordvpn allowlist add subnet 239.255.255.250/32
sudo nft list ruleset | grep -i allow

Les échecs de découverte surprennent parce qu’une imprimante ou un serveur multimédia peut être trouvé par une requête adressée au groupe plutôt que par une recherche de sa propre adresse. Ajouter le sous-réseau de l’hôte ne couvre pas automatiquement ce groupe, donc l’appareil reste invisible alors que sa page web se charge bien quand vous tapez l’adresse.

Gardez l’exception aussi étroite que le symptôme le permet. Un préfixe large tapé une fois est oublié pendant des années, et personne ne peut expliquer plus tard quelles machines il devait admettre. Supprimez les entrées quand le projet qui en avait besoin se termine, et vérifiez ce qui reste après une mise à jour.

Les versions récentes exposent aussi un réglage unique de découverte du LAN. Il est pratique, et il interagit avec la liste d’autorisation au lieu de s’empiler dessus : l’activer peut effacer des entrées existantes de sous-réseaux privés, et une règle manuelle de sous-réseau privé peut être refusée tant qu’il reste activé.

Les noms d’hôtes demandent une décision séparée

Autoriser un sous-réseau rétablit la connectivité par adresse et laisse le nommage intact. Les noms d’hôtes locaux sont toujours envoyés au résolveur que le client a configuré à la montée du tunnel, donc un nom qui se résolvait auparavant ne renvoie plus rien.

Pointer le client vers le résolveur du routeur règle cela en une étape et change discrètement ce que vous avez acheté. Chaque requête, pas seulement les locales, sort alors par le routeur, donc le tunnel ne protège plus la partie de votre navigation qui révèle vos intentions.

La route plus étroite conserve le résolveur du tunnel et ajoute les quelques noms qui comptent, soit comme domaine de recherche, soit comme entrées individuelles. Elle coûte plus d’attention et préserve la propriété que vous avez payée.

Vérifiez le résultat avec un appel au résolveur système plutôt qu’avec un navigateur. Les navigateurs exécutent de plus en plus leur propre résolution chiffrée et répondent volontiers par un chemin que votre shell n’utilise jamais, donc la barre d’adresse peut sembler saine alors que le résolveur système est encore cassé.

Le problème d’installation qui arrive en premier

Une bonne part de ces rapports n’atteint jamais le pare-feu, parce que la commande n’est pas là du tout. Le paquet d’amorçage de l’éditeur enregistre un dépôt et une clé de signature. Il n’installe pas le client, donc une commande absente juste après est le résultat attendu et non un échec.

Actualisez les listes de paquets et installez par nom. Si le gestionnaire de paquets se plaint d’une clé publique manquante, la clé n’a pas atterri là où il la cherche, et le correctif est de la placer là avant d’actualiser à nouveau.

Si le nom d’hôte du dépôt se résout en adresse privée, arrêtez-vous et lisez ce résultat deux fois. Vous exécutez peut-être déjà un tunnel dont le résolveur répond pour des noms publics, et réessayer l’installation produira le même message indéfiniment.

Écrivez-le avant de fermer le couvercle

Établissez que le tunnel est la seule chose qui a changé, puis autorisez la plus petite chose qui rétablit le symptôme. Gardez le nommage comme sa propre décision avec sa propre note.

Notez quelle exception existe pour quel appareil et qui l’a demandée. Un réseau local qui ne fonctionne que parce que quelqu’un a tapé un préfixe large est une décision qui a déjà survécu à sa raison.

Retestez après la mise à jour du client. La disposition du pare-feu change entre versions, et la liste d’autorisation du mois dernier n’est pas un fait sur ce mois-ci.