Publier un service LAN sur l’adresse propre de la passerelle VPN

Présenter un appareil LAN sur l’une des adresses de tunnel propres à la passerelle ne demande qu’une ligne de NAT. La connexion échoue quand même, car l’appareil qui répond n’a aucune idée que l’adresse du client est joignable via cette passerelle. Suivez le paquet du client vers l’intérieur, puis suivez la réponse vers l’extérieur, et la moitié manquante devient évidente.

Partez du point de vue du client

Le client de cet exemple se trouve dans le pool VPN 10.62.0.0/24 et se connecte à 10.62.0.1 sur le port 8080. Cette adresse appartient à la passerelle elle-même, donc le paquet arrive dans le noyau de la passerelle et non chez un autre pair. Derrière la passerelle, le LAN est 172.21.4.0/24. La passerelle détient 172.21.4.10 et l’appareil qui sert réellement HTTP est 172.21.4.40.

Une adresse qui appartient à un autre pair VPN n’est pas interchangeable avec l’adresse de service de la passerelle. Si le client se connecte à l’adresse d’un pair, aucune règle de la passerelle n’intervient et tout ce parcours est le mauvais cas.

Délimitez la traduction de destination à dessein

La version étroite présente un seul port et ne réécrit que la destination. Le paquet conserve son protocole et sa source, et c’est ce qui rend le reste du parcours intéressant.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Une règle sans critères de protocole et de port est la version large : elle conserve le port que le client a choisi et ne change que l’adresse. C’est légitime quand on veut présenter tout l’hôte, et faux quand un seul service était visé. Relisez la règle et confirmez le nom de l’interface. Une règle DNAT sur la mauvaise interface ne correspond à rien, ce qui produit le même délai qu’une règle absente et fait perdre une heure à regarder l’appareil.

Faites s’accorder la frontière de redirection

La traduction change l’en-tête, elle n’accorde pas la permission. Avec une politique de rejet par défaut, le flux redirigé a besoin de sa propre acceptation, et le sens retour a besoin de la règle d’établissement que votre politique possède probablement déjà.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Une acceptation inconditionnelle pour chaque flux DNAT est plus large que cette conception et autorisera aussi des mappages ajoutés plus tard par quelqu’un d’autre. Nommez la destination et le port, et laissez le reste fermé. Si les compteurs de la règle de redirection restent à zéro pendant que ceux du NAT montent, le paquet est rejeté avant votre règle. Lisez l’ordre des chaînes au lieu d’ajouter une seconde copie.

L’appareil doit bien répondre d’une manière ou d’une autre

Après la traduction, l’appareil voit une source dans 10.62.0.0/24. Sa réponse part vers sa passerelle par défaut, qui est le routeur du LAN et non la passerelle VPN, sauf si quelque chose lui dit le contraire. Deux dispositions corrigent cela, et elles ne sont pas équivalentes. Une route sur l’appareil ou sur le routeur du LAN envoie 10.62.0.0/24 vers 172.21.4.10 en préservant la source du client. Une traduction de source limitée cache le client derrière l’adresse LAN de la passerelle.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Choisissez selon ce dont le service a besoin. Une politique par client et des journaux parlants veulent la forme routée ; un appareil auquel on ne peut pas donner de route, ou un service qui doit simplement voir une adresse LAN, désignent la forme traduite. N’allez pas chercher une règle masquerade globale pour faire fonctionner une seule réponse. Elle cache chaque client à chaque destination et casse silencieusement les politiques qui dépendent des adresses source.

Ne testez pas depuis la passerelle elle-même

Une requête générée sur la passerelle vers 10.62.0.1 sort par la chaîne OUTPUT, pas par la chaîne PREROUTING entrante. Son échec ou sa réussite ne dit rien de la règle tournée vers le client, et c’est ainsi que les gens concluent qu’une règle qui fonctionne est cassée.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Lancez une vraie requête client et lisez les deux. L’entrée conntrack montre la traduction appliquée, et les captures montrent si la requête a traversé vers le LAN et si une réponse est revenue vers le tunnel. Utilisez une nouvelle connexion après avoir changé les règles, car l’état existant garde son mappage antérieur et continuera d’échouer à l’ancienne. Confirmez ensuite toute la conversation : l’adresse de l’appareil, la permission de redirection et la route de réponse décrivent le même flux.