Passerelle VPN VirtualBox pour le LAN : pont, route, retour

Les utilisateurs distants doivent atteindre une imprimante et un serveur de fichiers sur un LAN physique, et la seule machine Linux toujours allumée est une VM VirtualBox. Ponté la VM sur ce LAN, c’est la première moitié. La seconde moitié est une route de retour que chaque appareil du LAN utilisera réellement, et c’est la partie que la plupart des installations oublient. Quand elle manque, le tunnel se connecte, le client ping la passerelle, et rien d’autre ne répond.

Utilisez des adresses joignables

Réglez l’adaptateur LAN de la VM sur le mode Bridged Adapter approuvé pour ce réseau et donnez-lui une adresse via le processus d’attribution habituel. La VM apparaît alors sur le LAN physique comme n’importe quel autre hôte. Sa route par défaut doit toujours utiliser la vraie passerelle, afin que le transport chiffré vers le pair VPN reste joignable. N’utilisez pas l’adresse NAT par défaut de VirtualBox comme prochain saut du LAN, car cette adresse vit derrière un NAT virtuel et n’est pas on-link pour l’hôte ni pour les autres machines du LAN.

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

Vérifiez le chevauchement avec les réseaux domestiques des utilisateurs distants avant de choisir le pool. Un chevauchement devient une ambiguïté de routage qu’aucune configuration de serveur ne corrige.

Annoncez le LAN, puis transférez

Pour un serveur dont l’authentification et le transport sont déjà gérés, les lignes réseau ressemblent à ceci. Le push indique au client qui accepte comment atteindre le LAN, et il ne fait pas transférer quoi que ce soit à la VM par lui-même.

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

Activez le transfert IPv4 dans la configuration réseau persistante de la VM et autorisez le pool de clients à atteindre les services LAN prévus à la frontière de transfert de la VM. L’autorisation d’atteindre l’écouteur VPN est une règle distincte, et elle fonctionne déjà si le tunnel est monté.

La route de retour appartient au routeur du LAN

Les appareils du LAN répondent via leur passerelle par défaut, c’est-à-dire le routeur du LAN à 192.168.70.1. Ce routeur n’a aucune idée de l’endroit où vit 10.80.0.0/24 si on ne le lui dit pas. Ajoutez la route du pool à la configuration persistante prise en charge du routeur, en pointant vers l’adresse LAN de la VM. L’ajouter uniquement sur l’hôte VirtualBox répare les chemins qui consultent cet hôte, ce qui n’est pas chaque appareil du LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

Le pare-feu de la destination doit encore autoriser le pool de clients comme source. Une route transporte le paquet ; elle n’accorde pas le service.

Si le routeur du LAN ne peut pas être modifié, la traduction de source limitée sur la VM est l’alternative. Elle fait revenir les réponses sans la route et masque les adresses individuelles des clients au service du LAN.

Suivez un paquet de bout en bout

Un client à 10.80.0.25 envoie vers 192.168.70.40 par le tunnel. La VM transfère le paquet sur le LAN. Le service répond à son routeur, qui choisit la VM pour le pool de clients, et la VM renvoie le paquet via OpenVPN. Chaque saut de cette phrase est un endroit où la conception peut échouer.

Testez avec l’application réelle depuis un client distant, puis répétez après avoir rechargé la configuration gérée sur la VM et sur le routeur.

Si le client atteint la VM mais pas le service, vérifiez d’abord la route du routeur. Si le service reçoit la requête et que le client ne voit jamais la réponse, le chemin de retour est le suspect.