Comment donner à un LAN de test sa propre sortie WireGuard

Trois conceptions résolvent le même problème de laboratoire : un petit LAN doit sortir par un pair WireGuard tandis que la passerelle elle-même conserve son lien montant habituel. Le raccourci tentant consiste à déplacer la route par défaut du routeur dans le tunnel, mais cela casse le chemin de gestion de la machine et tout ce qu'elle transfère. L'option intéressante est le routage par politique limité à une interface et à un préfixe. Choisissez entre elles en répondant à trois questions sur la machine que vous avez réellement.

Décidez où vit la sortie

Première question : cet hôte transfère-t-il pour autre chose ? Une passerelle de laboratoire dédiée peut vivre avec une politique de transfert qui rejette par défaut. Un routeur chargé de production ne le peut pas, et superposer un jeu de règles concurrent sur un pare-feu géré est exactement la façon dont les pannes s'organisent. Deuxième : pouvez-vous posséder deux objets de politique et leur ordre à travers les redémarrages ? Troisième : le pair dont vous disposez autorise-t-il l'adresse source de votre tunnel et offre-t-il une sortie Internet ? Un pair qui n'expose qu'un réseau privé est un autre produit, et aucun changement de routage local n'y remédie. Si une réponse est non, placez plutôt la sortie dans un espace de noms ou dans une machine virtuelle jetable.

Un espace de noms ou une VM coûte de la mémoire et vous donne un rayon d'impact net. Le routage par politique coûte deux règles et vous laisse une seule machine à déboguer.

Choisissez la sortie qui autorise votre source

La plupart des échecs dans ce laboratoire se produisent avant même qu'une seule règle de pare-feu existe. L'opérateur de la sortie doit accepter l'adresse source que vos paquets portent après la traduction, qui dans cette conception est l'adresse du tunnel et non le préfixe du LAN. C'est pourquoi le masquage fait partie de la conception dès le départ et non d'un ajout tardif.

Confirmez trois choses avec l'opérateur : le pair autorise l'adresse de votre tunnel, il transfère IPv4 au lieu de terminer sur lui-même, et il applique un NAT de sortie. Sans la première, vos paquets arrivent et disparaissent. Sans la troisième, ils partent avec une source privée et meurent au saut suivant. Vérifiez ensuite que wg-quick n'installe pas sa propre route par défaut, ce que Table = off empêche ; ce réglage supprime la création de routes, pas les contrôles AllowedIPs du pair ni sa gestion du DNS.

Deux objets de politique font le pilotage

Le pilotage exige une table et une règle. La table contient deux routes : le préfixe du LAN sortant de l'interface LAN et une route par défaut sortant du tunnel. La règle envoie dans la table le trafic qui arrive sur l'interface LAN et porte ce préfixe. Utilisez le sélecteur iif en plus de la correspondance de source, car les paquets WireGuard de la passerelle naissent localement et ne correspondent jamais à une interface entrante.

Le garde-fou vient avant la recherche, pas après. Cet ordre est toute la propriété de sûreté de la conception.

Le garde-fou est une seconde règle sur le même sélecteur dont le verdict est unreachable. Donnez-lui une priorité numérique plus élevée afin que la recherche gagne encore tant que le tunnel est monté. Quand la route du tunnel disparaît, la recherche ne renvoie rien et le garde-fou arrête la recherche au lieu de la laisser retomber sur la route par défaut WAN de la table principale.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Fermez la brèche de repli avant de l'ouvrir

Installez d'abord le garde-fou et ensuite la recherche. Faire l'inverse laisse une fenêtre de quelques secondes pendant laquelle le trafic d'un client de test peut atteindre le lien montant.

Le filtre complète le tableau. Dans le crochet forward, acceptez la direction du LAN vers le tunnel pour le préfixe de test et la direction de retour établie, puis rejetez tout le reste ; le NAT de ce préfixe vers l'interface du tunnel va dans postrouting. Laisser policy drop sur la chaîne de transfert est ce qui transforme une route absente en silence plutôt qu'en fuite. Le filtrage de chemin inverse exige le mode permissif sur l'interface du tunnel, car une source publique qui arrive décapsulée a sa meilleure route inverse du côté WAN. Linux retient la valeur la plus élevée entre all et celle par interface, donc régler l'interface du tunnel n'est pas la même chose qu'affaiblir la validation partout.

Prouvez-le par le cas de défaillance

Posez au noyau une question précise en nommant l'adresse source du client et l'interface par laquelle il arrive. Une recherche sans les deux répond à une autre question et paraîtra correcte dans les deux cas. Regardez ensuite les compteurs du pare-feu, l'état de transfert du pair et le service du client lui-même.

Testez le retrait correctement. Arrêtez le tunnel en laissant la règle et le filtre en place : le client devrait caler et le trafic propre de la passerelle devrait continuer de fonctionner. Arrêtez ensuite le pair sans toucher à l'interface locale, car c'est le cas qui attrape les conceptions reposant uniquement sur la présence de la route. Enfin, redémarrez et revérifiez l'ordre des règles, car un crochet de démontage qui retire le garde-fou rend toute la conception à la table principale. Notez le numéro de table, les priorités et les noms d'interface sur le ticket de changement, car la prochaine personne qui ajoutera une règle sera celle qui cassera cela.