Masquerade ou routage par politique : le trafic du LAN via une passerelle VPN

Placer tout un LAN derrière un tunnel VPN est la partie facile ; décider comment le côté distant voit ces clients ne l’est pas. Le masquerade réécrit chaque source du LAN vers l’adresse du tunnel de la passerelle, si bien que l’extrémité distante répond à un seul pair. Le routage par politique conserve les adresses d’origine et exige que l’extrémité distante sache comment les atteindre. Ni l’un ni l’autre n’est la valeur par défaut ; le choix découle de qui possède le côté distant et de l’importance de l’identité par appareil.

Les deux conceptions promettent des choses différentes

Le masquerade réduit le LAN à un seul hôte visible : la passerelle. Le réseau distant répond à cette adresse unique, et la passerelle traduit les réponses vers le client qui a lancé le flux. Aucune route vers vos préfixes privés n’est nécessaire côté distant, ce qui permet à cette conception de survivre à un fournisseur qui refuse de les transporter. La passerelle devient aussi la source de chaque connexion, donc le côté distant ne peut pas distinguer deux clients.

Le routage par politique garde chaque adresse client intacte. Le réseau distant voit la source réelle et peut la journaliser, appliquer une règle par hôte ou envoyer la réponse directement à cette adresse. Cette visibilité est tout l’intérêt, et elle vient avec une obligation : le côté distant doit avoir une route pour le préfixe du LAN qui repasse par le tunnel. Planifiez cette route avant d’activer la règle, car le tunnel montera de toute façon et seules les réponses manqueront.

Les modes de défaillance diffèrent autant que les promesses. Une règle de masquerade absente produit des paquets qui partent avec des sources privées et ne reviennent jamais. Une route de retour absente produit le même symptôme en routage par politique, mais la correction revient au routeur distant, pas à la passerelle.

Le masquerade : un seul pair côté distant

Le chemin du masquerade a un ordre qui compte. Le transfert doit être activé avant qu’une règle NAT ne serve à quelque chose, la table de filtrage doit autoriser le transit dans les deux sens, et c’est seulement alors que la traduction s’applique sur l’interface du tunnel.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Les clients ont toujours besoin d’un chemin vers la passerelle. Soit la passerelle est leur routeur par défaut, soit ils portent une route spécifique pour le préfixe distant ; si un routeur séparé reste la passerelle par défaut, ce routeur a besoin d’une route statique vers les destinations du tunnel, sinon le paquet part vers le mauvais saut avant que la passerelle ne le voie.

Le DNS est une décision à part. Un résolveur côté distant ne répond que si sa réponse peut revenir vers le client. Sous masquerade, la requête semble venir de la passerelle, donc la route de retour du résolveur est déjà satisfaite ; sous routage par politique, le résolveur a besoin de la même route de retour que tout autre service distant.

Routage par politique : gardez la source, ajoutez une route de retour

Le routage par politique commence par une table et une règle qui la sélectionne. Le trafic entrant par l’interface du LAN est envoyé vers une table dédiée, et cette table porte une route par défaut à travers le tunnel. La table principale reste intacte, donc le trafic originaire de la passerelle elle-même peut suivre un autre chemin.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Le côté distant doit ensuite router le préfixe du LAN en retour par le tunnel. C’est une configuration sur le routeur distant, pas sur cette passerelle. La passerelle doit aussi accepter les réponses qui arrivent sur une interface différente de celle que la table principale prédirait ; le filtrage lâche du chemin inverse (rp_filter réglé à 2) est l’ajustement habituel quand le mode strict rejette ces paquets.

Quand deux tunnels sont actifs, étiquetez chaque flux à son entrée et laissez l’étiquette choisir la table. Une règle qui ne regarde que l’interface d’entrée envoie le trafic des deux tunnels vers la même table, si bien que le second tunnel vole des flux au premier. Testez cette étiquette avec une connexion qui survit à une reconnexion, car c’est là qu’une politique mixte se révèle.

Décidez selon la propriété et selon ce que le côté distant journalise

Si le tunnel se termine chez un fournisseur, utilisez le masquerade. Cet opérateur ne routtera pas vos plages privées de LAN, et il n’a aucune raison de distinguer des clients individuels derrière votre passerelle. Un seul pair visible est le seul modèle que sa politique prenne en charge, alors donnez-le-lui et gardez la traduction à votre bord. Le fournisseur voit un pair, ce qui est exactement ce que sa politique attend, et vos clients héritent de cette identité unique.

Si les deux extrémités sont à vous et que les services distants agissent sur les adresses source, le routage par politique mérite sa route supplémentaire. Les règles de pare-feu, l’accès par utilisateur et les journaux d’audit peuvent alors distinguer les clients. Si le côté distant n’a besoin que d’être joignable, le masquerade est plus simple et élimine une classe d’erreurs de route de retour.

Les conceptions hybrides sont normales : routage par politique dans votre propre réseau, masquerade au bord du fournisseur. L’important est de noter quel saut traduit et quel saut route, car une règle NAT ajoutée par accident pour un client cache la source de tous les clients de la même chaîne.

Vérifiez depuis un client, puis depuis un second client

Lancez le test là où le trafic commence. Vérifiez la route qu’utilise l’hôte, regardez le paquet apparaître sur l’interface du tunnel et inspectez conntrack pour la traduction. Cette séquence prouve que le paquet a suivi le chemin prévu, et non qu’il est simplement arrivé quelque part.

Répétez le test après une reconnexion. Une règle de masquerade qui nomme l’interface survit à une nouvelle adresse de tunnel ; une règle qui nomme l’ancienne adresse n’y survit pas. Testez ensuite un second hôte du LAN, car une conception qui fonctionne sur une machine dépend souvent de la route propre à cette machine plutôt que de la politique de la passerelle.

Notez le modèle choisi, la source traduite ou préservée et le propriétaire de la route de retour dans les notes de la passerelle. Sinon, la prochaine personne qui ajoutera un client ou un tunnel devra deviner, et deviner est la façon dont une configuration LAN-vers-VPN qui fonctionne devient partielle.