TL;DR : route <réseau> <masque> net_gateway
. « net_gateway » est un mot-clé qui désigne l'IP de la passerelle par défaut du réseau local. Elle sera récupérée automatiquement dans la table de routage du système par OpenVPN.
D'habitude, quand j'utilise OpenVPN, c'est pour encapsuler tout mon trafic dans un VPN. Sur le client, j'utilise donc la directive de configuration redirect-gateway def1
.
Son effet ? Lorsque le VPN est activé, elle ajoute une route vers l'IP du serveur VPN dont le prochain saut est l'IP de la passerelle par défaut du réseau auquel je suis connecté à l'instant T, puis, elle ajoute deux routes, 0.0.0.0/1 et 128.0.0.0/1, dont le prochain saut est le serveur VPN. Ces deux routes l'emportent sur la route par défaut, 0.0.0.0/0, ajoutée par le client DHCP ou à la mano, car elles sont plus spécifiques (0.0.0.0/0 = tout l'adressage IPv4, 0.0.0.0/1 = seulement la première moitié de cet adressage). Ainsi, tout le trafic est encapsulé dans le VPN sauf le flux qui le soutient qui est envoyé au serveur VPN en utilisant la route dédiée qui envoie le trafic à la passerelle par défaut du réseau.
Aujourd'hui, je ne veux pas donner un accès à Internet aux utilisateurs de mon VPN. Je veux que seuls les réseaux de l'organisation soient accessibles via le VPN. Dans la configuration d'OpenVPN, j'ajoute donc route 198.18.0.0 255.255.0.0
. En vrai, j'ajoute une ligne de ce type pour chaque réseau de l'organisation. Sauf que l'IP publique du serveur VPN, 198.18.0.42 est dans le réseau 198.18.0.0/16). Donc, quand le VPN deviendra actif, la route ainsi ajoutée dirigera le flux soutenant le VPN… à l'intérieur du VPN ! Boucle. Le VPN cessera de fonctionner.
Ce qu'il faudrait, c'est ajouter une route plus spécifique vers le serveur VPN… Mais ça suppose de connaître l'IP de la passerelle par défaut du réseau local auquel l'utilisateur du VPN est connecté. Ça change en fonction du réseau ! On pourrait coder un script qui se lancerait lorsque le VPN devient actif (c'est la directive de configuration `route-up'). Mais il faudrait qu'il fonctionne sur winwin, Mac OS, GNU/Linux, Android, IOS, etc. Infaisable.
Heureusement, OpenVPN a tout prévu. Il propose le mot-clé net_gateway
pour la directive de configuration route
. Ce mot-clé désigne l'IP de la passerelle par défaut du réseau local. Elle sera récupérée automatiquement dans la table de routage du système par OpenVPN.
Ainsi, pour faire ce que je veux, je mets les deux lignes suivantes dans la configuration de mon OpenVPN :
route 198.18.0.0 255.255.0.0
route 198.18.0.42 255.255.255.255 net_gateway
Tout le trafic destiné au réseau 198.18.0.0/16 sera envoyé dans le VPN. Tout échange avec le serveur VPN (198.18.0.42) sera envoyé en dehors du VPN. Le flux UDP ou TCP chifffré échangé avec le serveur VPN sera donc envoyé en dehors du VPN. Il n'y a plus de problème de boucle.
Même le plus récent manuel d'OpenVPN indique que le mot-clé « net_gateway » ne fonctionne pas sur tous les systèmes. Cela me semble être exagéré. J'ai essayé et je peux affirmer que cela fonctionne sur winwin 7, winwin 10, Mac OS X 10.11, GNU/Linux Debian Stretch, Ubuntu 16.04, Android (7 ?) et IOS (version ?).
Évidemment, pour ne pas encombrer le fichier de configuration de mes clients et pour rendre facile l'ajout et la suppression de routes (sans avoir besoin de faire récupérer un nouveau fichier de configuration à tous mes utilisateurs VPN), je configure les clients depuis la configuration du serveur. Les deux lignes précédentes deviennent donc :
push "route 198.18.0.0 255.255.0.0"
push "route 198.18.0.42 255.255.255.255 net_gateway"
Notons que ce mot-clé permet également de ne pas encapsuler des destinations spécifiques dans un VPN avec route par défaut (redirect-gateway def1
). Genre ne pas encapsuler Netflix (qui bloque les VPN, proxy, etc.). Genre ne pas encapsuler le trafic vers un résolveur DNS local (parfois, on peut avoir une bonne raison de ne pas utiliser les DNS du fournisseur de VPN genre continuer à pouvoir résoudre des noms locaux au réseau auquel on est connecté). Genre ne pas encapsuler le trafic vers les plages d'adresses RFC1918 (privées) utilisées sur le réseau local, etc.