Comment router un seul site web hors de votre tunnel WireGuard

Exclure un nom d'hôte est quelque chose qu'un tunnel ne peut pas faire. Une route, en revanche, peut diriger une seule adresse au-delà du tunnel et vers l'extérieur par la passerelle domestique, et cela suffit généralement pour un site. Le piège est que tout ce qui se trouve en aval de la route doit s'accorder : le pare-feu doit laisser sortir le paquet, le DNS doit renvoyer l'adresse que vous avez routée, et le site doit continuer d'utiliser cette adresse. Quand l'un des trois dérive, l'exception cesse de fonctionner sans se faire annoncer.

Lisez l'adresse de destination avant de toucher au tunnel

Chargez le site une fois avec le tunnel actif, puis regardez l'adresse du pair à laquelle le navigateur s'est réellement connecté. Sous Linux, ss -tunp liste l'adresse distante de chaque socket ouvert, et dig +short sur le même nom montre ce que le résolveur a renvoyé. Gardez les deux nombres sous les yeux.

Les deux réponses ne concordent souvent pas, et cette divergence est tout le problème. Les grands sites placent un réseau de contenu devant leur origine, si bien que l'adresse que votre résolveur renvoie maintenant n'est peut-être pas celle que le navigateur a utilisée il y a une minute. Routez ce que vous avez observé sur le socket, pas ce qu'énumère un guide plus ancien. Si les réponses ne cessent de tourner entre les régions, une exception d'adresse est le mauvais outil pour ce site précis.

Relancez la recherche une seconde fois depuis un autre réseau et notez la réponse IPv6 avec celle en IPv4. Un tunnel qui transporte les deux familles a besoin d'une exception dans les deux, sinon le navigateur retombe silencieusement sur le chemin IPv6 que vous n'avez jamais touché. Notez les adresses et la date quelque part où vous retournerez voir.

Placez une route d'hôte sur le client

Supposons que l'interface s'appelle home-wg et que le routeur LAN soit à 192.168.1.1. NetworkManager prend une route dont la passerelle est ce routeur et dont la longueur de préfixe couvre les 32 bits entiers, et le noyau la préfère parce que le préfixe le plus long gagne.

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

La passerelle doit être joignable sans le tunnel ; pointer le saut suivant vers l'adresse du tunnel va à l'encontre du but, car le paquet rentrerait dans l'interface que vous cherchez à éviter. Une fois la connexion remontée, ip route get pour l'exception devrait afficher la passerelle LAN, et la même commande pour un résolveur public devrait toujours afficher le périphérique du tunnel.

Un profil wg-quick n'a pas de champ de routes, donc la même exception vit dans une ligne PostUp qui ajoute la route d'hôte à la table principale avec l'interface LAN comme périphérique. Abaissez puis remontez l'interface après l'édition, car une interface en cours d'exécution ne relit jamais son fichier. Les règles fwmark que wg-quick installe ne pilotent que ses propres paquets encapsulés, donc le trafic ordinaire du navigateur suit toujours la table principale et trouve votre /32.

Le coupe-circuit est la prochaine chose qui bloque cela

Une politique de pare-feu qui n'admet le trafic que sur l'interface du tunnel rejettera l'exception même quand la route est parfaitement correcte. Lisez les règles derrière l'interrupteur au lieu de faire confiance à l'interrupteur, car celles qui implémentent un coupe-circuit sont généralement limitées à un nom d'interface.

Ce que vous voulez, c'est une autorisation étroite pour l'interface physique et cette destination unique, placée avant le rejet, tandis que la politique par défaut reste intacte. Mettre complètement en pause le coupe-circuit prouve le point, mais laisse aussi la machine exposée tant que vous oubliez de le réactiver.

Testez les deux directions séparément. Une requête vers l'adresse de l'exception devrait réussir tandis qu'une requête vers un site sans rapport sort toujours par le tunnel. Si les deux réussissent mais que la seconde rapporte l'adresse de la maison, c'est l'ordre des règles du pare-feu qui est faux, pas la route.

Le DNS décide de l'adresse que le navigateur contacte

Quand le nom se résout à l'intérieur du tunnel, le résolveur du fournisseur peut répondre avec une adresse différente de celle du résolveur local. Votre route s'applique alors à une adresse que le navigateur ne contacte jamais, et la page se charge par le tunnel comme si rien n'avait changé. Cette panne ressemble à une exception cassée alors même que la table de routage est correcte.

Envoyez aussi les requêtes de ce nom via le résolveur local, ou ignorez complètement les noms et testez l'adresse directement. Séparer l'adresse en laissant le DNS à l'intérieur du tunnel est la version à moitié terminée la plus courante de cette configuration, et c'est aussi la plus difficile à remarquer, car le site continue de fonctionner, juste pas comme vous le vouliez.

La même exception sur le routeur, une fois, pour chaque appareil

Quand le tunnel tourne sur le routeur, la route d'hôte appartient à la table de routage par politiques du routeur et pointe vers la passerelle WAN plutôt que vers celle du LAN. Chaque appareil derrière en hérite l'exception, ce qui compte pour un boîtier de streaming ou un portable de travail dont vous ne pouvez pas changer les réglages réseau.

Laissez le tunnel comme sortie par défaut pour tous les autres clients, puis vérifiez depuis une machine cliente plutôt que depuis la console du routeur. Chargez le site de l'exception et un second site dans la même session de navigateur et comparez les adresses de sortie ; si le second affiche toujours le tunnel, la table de politiques fait ce que vous avez demandé.

Notez l'adresse, la date et la raison dans les notes du routeur. Une exception construite autour d'une adresse qui bouge plus tard devient une panne que personne ne saura expliquer dans un an, et la correction ressemble toujours à un mystère jusqu'à ce que quelqu'un retrouve la vieille note.