Router le trafic des VM du réseau host-only via un serveur TUN OpenVPN

Les adaptateurs host-only créent un réseau virtuel local, et les tunnels TUN routés transportent des paquets IP entre adresses. Ni l’un ni l’autre n’est un pont vers l’autre, c’est pourquoi une configuration qui fonctionne doit dire qui transfère et à qui appartient la route de retour. Inverser ces deux affectations, et l’invité répond au tunnel avec une source que le client du tunnel n’a jamais demandée. La conception ci-dessous maintient les deux préfixes distincts et rend le chemin de retour explicite.

Deux réseaux, deux préfixes

Donnez au pool du tunnel et au réseau host-only des préfixes différents et ne réutilisez jamais l’un pour l’autre. Dans cet exemple, le pool VPN est 10.44.0.0/24 et le réseau host-only est 192.168.99.0/24, avec l’hôte à 192.168.99.1 et un invité à 192.168.99.20. Attribuer le même préfixe à la fois à un périphérique TUN et à l’adaptateur host-only ne les relie pas. Cela crée deux revendications sur une même plage d’adresses, et la table de routage répond alors pour celle qu’elle a gardée par hasard.

L’adaptateur host-only existe sur l’hôte et à l’intérieur de l’invité, et il n’a pas de chemin hors de la machine par lui-même. Les raccordements en pont et NAT ont une exposition différente, et passer en mode pont n’est pas une condition pour joindre un seul service de l’invité.

L’hôte détient déjà le chemin

Regardez ce qui existe avant d’ajouter quoi que ce soit. L’hôte a une interface sur le réseau host-only et une route pour ce préfixe, toutes deux créées au démarrage de l’adaptateur.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

La troisième ligne est le mécanisme qui transforme l’hôte en saut. Sans elle, un paquet arrivant du tunnel est adressé à un réseau que l’hôte peut atteindre mais ne transférera pas. Le transfert est nécessaire et non suffisant. La politique de filtrage décide encore si un flux donné entre l’interface du tunnel et l’interface host-only est autorisé, et cette décision doit être écrite plutôt que reléguée à une politique par défaut que personne n’a lue.

Poussez la route, puis filtrez ce qu’elle atteint

Le serveur peut fournir le préfixe host-only aux clients qui acceptent les routes poussées, ce qui est le même mécanisme que pour tout autre sous-réseau derrière le tunnel.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Ces deux règles autorisent un seul service dans un sens et ses réponses. Une route qui atteint tout le préfixe et un filtre qui autorise un seul port forment une combinaison délibérée ; une route plus une acceptation inconditionnelle, c’est ainsi qu’un service de laboratoire devient un service exposé. Une route poussée n’est pas non plus une autorisation. Le client l’accepte, l’hôte la transfère, et le pare-feu de l’invité et le service lui-même ont encore voix au chapitre.

L’invité a besoin d’un chemin de retour

Un invité joint depuis 10.44.0.x doit envoyer ses réponses à l’adresse host-only de l’hôte, ou l’hôte doit traduire la source. Recevoir une adresse du DHCP de VirtualBox ne dit rien de l’une ou l’autre disposition.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Ajouter cette route dans l’invité préserve la source d’origine, ce qui garde une politique et des journaux par client significatifs. La traduction de source limitée sur l’hôte est l’alternative, et elle fonctionne, au prix de masquer quel client s’est connecté. Le chevauchement est l’autre mode de défaillance. Un client distant dont le réseau local utilise déjà 192.168.99.0/24 lira la route poussée comme son propre réseau, et aucun changement côté serveur ne règle cette ambiguïté. Renumérotez un côté ou choisissez un préfixe peu susceptible d’entrer en collision.

Un périphérique TUN transporte des paquets IP, donc ajouter une passerelle par défaut dans un invité ne transforme pas le tunnel en segment Ethernet avec l’adaptateur host-only. Le pont TAP est une conception différente avec son propre support client et sa propre propriété d’adresses, et mélanger les deux descriptions mène à des configurations qui ne convergent jamais.

Vérifiez, puis faites en sorte que cela survive à un redémarrage

Testez un service inoffensif depuis un client distant ordinaire, vérifiez la route de retour de l’invité et confirmez qu’un service que vous n’avez pas autorisé est refusé plutôt que lent.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Redémarrez ensuite le service VPN et le réseau de la machine virtuelle, puis répétez les mêmes trois vérifications. Une route ajoutée à la main survit jusqu’au redémarrage suivant, et une configuration qui ne fonctionne que dans une session à chaud n’est pas une conception. Notez ensemble les deux préfixes, la politique de transfert et la route de l’invité. Celui qui ajoutera la prochaine machine virtuelle aura besoin des trois et, sinon, les redécouvrira une connexion échouée après l’autre.