Acheminer un sous-réseau LAN via OpenVPN et garder la route par défaut

Les machines qui routent pour un LAN et composent en même temps un VPN finissent dans la même dispute avec elles-mêmes : le tunnel veut posséder la route par défaut, et le LAN a besoin de la récupérer. Quand OpenVPN se connecte, il peut installer une route par défaut à travers le tunnel ou une paire de demi-routes par défaut, ce qui est juste pour un portable et faux pour une passerelle dont les voisins attendent des réponses depuis son adresse LAN. La réponse n’est pas de se passer du VPN. La réponse est de donner aux deux décisions des tables différentes.

Une route par défaut, deux propriétaires

Le trafic transféré et le trafic d’origine locale n’ont pas à emprunter le même chemin. Les clients du LAN n’ont besoin du tunnel que pour les destinations que vous choisissez, tandis que les sessions d’administration de l’hôte lui-même et ses réponses à ces clients ont besoin de la route par défaut du LAN. Mélanger les deux dans la table principale impose une seule réponse à deux questions différentes.

OpenVPN a un commutateur exactement pour cela. route-noexec empêche le client de toucher du tout à la table principale, et les valeurs qu’il aurait utilisées sont exportées vers un script route-up sous les noms route_vpn_gateway, dev et les adresses de l’interface. Vous décidez ensuite quelle table reçoit quelle route, dans du code que vous pourrez relire plus tard.

Table de politique ou réécriture de la principale

La table séparée est la seule option qui passe à l’échelle au-delà d’un sous-réseau. Nommez-la une fois, puis faites-y référence par son nom pour que personne n’ait à retenir un numéro :

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Les adresses ici sont des exemples. Remplacez le préfixe LAN, la passerelle du tunnel et le nom de l’appareil de votre propre déploiement avant d’exécuter quoi que ce soit.

La règle doit aussi correspondre à l’hôte

Une règle qui ne correspond qu’au préfixe LAN couvre les paquets transférés. Elle ne couvre pas le trafic que la passerelle elle-même origine, ni les réponses qu’elle renvoie aux clients du LAN, qui portent l’adresse LAN de la passerelle comme source. Ces recherches retombent sur main et peuvent encore sortir par le tunnel.

Ajoutez une seconde règle pour l’adresse LAN propre à la passerelle, ou élargissez la première règle à un ensemble qui inclut les deux. L’ordre compte : placez la règle la plus précise en premier et vérifiez le résultat avec une recherche qui nomme la source explicitement.

ip route get 203.0.113.9 from 192.168.50.1

Si cela indique l’appareil du tunnel pour une destination qui devrait rester locale, l’ensemble de règles est faux, quoi que contienne la table.

NAT ou route de l’autre côté

Le serveur VPN connaît le sous-réseau du tunnel et rien d’autre. Les paquets qui arrivent avec une adresse source LAN n’ont pas de chemin de retour à moins que quelqu’un en fournisse un, et il y a exactement deux façons d’en fournir un. Ajouter une route pour le préfixe LAN sur le serveur garde la source d’origine visible de bout en bout, ce qu’un design audité veut généralement. Le masquage sur la passerelle réécrit la source en l’adresse du tunnel et ne demande aucune coopération du serveur.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Choisissez NAT quand vous ne contrôlez pas le serveur et ne pouvez pas y ajouter de routes. Choisissez la route côté serveur quand les journaux, le contrôle d’accès ou la symétrie du chemin de retour comptent, car le masquage efface l’adresse d’origine de tout ce que l’autre côté enregistre.

Dans les deux cas, le transfert doit être activé, et un filtrage strict du chemin inverse peut rejeter la réponse quand main n’aurait pas choisi le tunnel pour cette source. Vérifiez la valeur effective avant d’accuser le tunnel.

Faire survivre la séparation à une reconnexion

Les règles et routes ajoutées à la main disparaissent quand l’interface est recréée, et une entrée de table périmée peut survivre à la session qui la justifiait. Placez la règle de table, la route du tunnel et l’entrée de masquage dans le script route-up du client, et videz la table en tête du script pour qu’une ancienne passerelle ne survive pas dans la nouvelle session.

Vérifiez des deux côtés : une recherche sur la passerelle avec la source LAN, et une vraie requête d’un client du LAN vers une destination qui doit traverser le tunnel. Une route qui existe mais n’est jamais sélectionnée se comporte exactement comme aucune route, jusqu’à ce que vous lisiez les compteurs.