Laboratoire VPN sous VirtualBox : VM passerelle ou réseau hôte uniquement

Vous devez décider de la quantité de machinerie que mérite votre laboratoire VPN. Une VM passerelle routée entre deux segments VirtualBox reproduit la traduction d'adresses, le chemin de retour et la position du pare-feu derrière lequel se trouve un client réel. Un seul segment hôte uniquement vous donne une porte contrôlée et rien de plus. La version passerelle coûte trois invités et une table de routage que vous maintenez ; la version hôte uniquement coûte un invité et une politique. Trois questions les séparent, et la troisième décide si votre test peut seulement réussir.

Répondez à trois questions avant de cloner quoi que ce soit

Commencez par ce que le serveur VPN doit observer. Si le serveur doit voir une adresse source qui n'est pas celle de l'invité de test, quelque chose doit traduire entre les deux, et ce quelque chose doit être un routeur que vous contrôlez. Le réseau hôte uniquement donne à l'hôte un adaptateur sur le segment de l'invité, pas un traducteur. Quand l'invité doit ensuite atteindre quelque chose à l'extérieur, vous attachez un adaptateur NAT, et le moteur NAT de VirtualBox réécrit la source sans vous demander.

Demandez ensuite si l'invité peut atteindre quoi que ce soit hormis par le tunnel. Cette réponse choisit interne ou hôte uniquement, et c'est la question que la plupart des descriptions de laboratoire sautent. Enfin, demandez ce qui doit se passer quand le tunnel tombe, car cela décide de la politique et non de la topologie, et un laboratoire qui ne prouve que le chemin heureux n'a presque rien testé.

Câblez les trois rôles avec des réseaux internes

Utilisez trois invités et deux segments nommés, la passerelle étant la seule machine à avoir un adaptateur sur les deux :

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

Il n'y a pas d'étape de création séparée pour un réseau interne. La chaîne dans --intnet1 est le segment : deux machines ne le partagent que si le nom correspond exactement, et rien sur l'hôte n'y est attaché. Cette dernière propriété est la raison pour laquelle le laboratoire se répète proprement, car les routes de l'hôte, son propre client VPN et son pare-feu ne peuvent pas atteindre les invités par accident. Un segment interne n'a pas non plus de serveur DHCP sauf si vous en ajoutez un, donc les adresses statiques sont le chemin le plus court.

Donnez au client uniquement son adresse WAN, avec une passerelle par défaut pointant vers l'adresse WAN de la passerelle. Le serveur reçoit une adresse LAN et utilise l'adresse LAN de la passerelle comme passerelle par défaut. Un invité qui garde deux adresses sur un segment, ou une route égarée vers l'autre segment, a un chemin autour du routeur, et les tests ci-dessous vous mentiront.

Je garde un fichier texte à côté des noms de VM avec les quatre adresses et les deux noms de segment, et je le colle dans chaque shell. Des semaines plus tard, quand un changement de profil casse quelque chose, ce fichier est la différence entre déboguer le profil et déboguer ma propre mémoire.

Choisissez interne ou hôte uniquement pour le segment qui ne doit pas fuir

Le mode hôte uniquement crée un adaptateur virtuel sur l'hôte lui-même, généralement vboxnet0, et donne à l'hôte une adresse sur le segment de l'invité. C'est pratique pour l'administration et fatal pour un test d'isolation, car l'hôte peut désormais atteindre l'invité directement et chaque service côté hôte devient un chemin possible. Le mode interne n'a aucun adaptateur hôte. Les deux modes se confondent facilement dans le panneau des paramètres réseau, alors vérifiez la différence documentée plutôt que l'étiquette (voir la page détails du réseau VirtualBox).

Pour un invité qui doit utiliser le tunnel, l'interne est le choix par défaut le plus sûr, avec la passerelle comme seule sortie. Si vous gardez hôte uniquement, traitez l'adaptateur hôte comme un chemin de gestion et dites-le à voix haute : l'hôte peut atteindre l'invité, et l'invité ne doit pas pouvoir utiliser l'hôte comme sortie.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

L'isolation que vous pouvez prouver est celle que vous avez configurée. Un invité avec un adaptateur interne, une route par défaut sur la passerelle et aucun adaptateur NAT n'a aucun chemin qui contourne la passerelle. Un invité avec un adaptateur hôte uniquement et un adaptateur NAT a deux chemins, et un seul est celui que vous vouliez tester.

Routez et traduisez sur la passerelle, puis faites-la échouer fermée

VirtualBox ne transfère pas entre segments ; c'est l'invité qui le fait. Avec la VM du serveur VPN derrière la passerelle, activez le transfert et traduisez le trafic du client au moment où il sort vers le serveur :

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Avec cette règle, le serveur voit l'adresse LAN de la passerelle au lieu de celle du client, et c'est à cela que ressemble un client réel derrière un NAT d'opérateur pour une tête de réseau. Enregistrez la valeur sysctl dans /etc/sysctl.d/ et la règle dans le service de pare-feu utilisé par la distribution, sinon un redémarrage ramène silencieusement le laboratoire à un état routé mais non traduit.

Le transfert n'est pas une autorisation. Sous la politique FORWARD par défaut de ACCEPT, un invité dont la route par défaut pointe vers la passerelle sort par l'interface choisie par la table de routage, avec ou sans tunnel. Si la passerelle a aussi un adaptateur NAT pour l'installation de paquets, cet adaptateur est une sortie non chiffrée fonctionnelle à l'instant où le tunnel tombe, et votre test réservé au VPN n'a jamais été un test réservé au VPN.

Quand le serveur est distant et que la passerelle termine elle-même le tunnel, la même décision pointe vers l'interface du tunnel, pas vers la carte réseau qui atteint internet :

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Gardez le transport extérieur propre au tunnel et une route de gestion hors bande séparés du trafic transféré. Si le seul moyen de réparer la passerelle passe par le tunnel que vous déboguez, le laboratoire devient un exercice de verrouillage. Une console série, un adaptateur de gestion hôte uniquement ou un instantané d'un état sain connu coûtent moins cher que la récupération manuelle d'un routeur cassé.

Vérifiez le chemin depuis l'invité, pas depuis l'hôte

Travaillez vers l'extérieur. Confirmez que le client atteint l'adresse WAN de la passerelle, puis le serveur à travers la passerelle, puis qu'une connexion au port VPN sort et revient. Une capture sur les deux interfaces de la passerelle montre si la réponse arrive et est abandonnée sur le chemin de retour, ce qu'une capture sur le client seul ne peut pas distinguer :

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Prouvez ensuite la sortie. Demandez depuis l'invité à un service de réflexion d'adresses quelle source il voit et comparez-la à l'adresse de sortie de la passerelle ; si la réponse correspond à l'adresse de l'hôte, un chemin autour du tunnel existe. Vérifiez quel résolveur l'invité utilise réellement, et vérifiez IPv6 séparément, car un segment où IPv6 est activé alors que le tunnel ne transporte que IPv4 fuit par conception et non par accident.

Enfin, cassez-le exprès. Arrêtez le tunnel, ou bloquez son port extérieur, et ouvrez une nouvelle connexion depuis l'invité. Elle doit échouer, et la raison doit être une que vous pouvez nommer : pas de route, une règle de rejet ou un résolveur mort. Redémarrez le tunnel et confirmez que l'invité récupère sans reconstruire le réseau. Si un VPN maillé comme Hamachi ou ZeroTier partage le laboratoire, rappelez-vous qu'un adaptateur ponté suit le nom de l'adaptateur, pas le maillage, donc le pont doit être réorienté après que le client a installé son propre adaptateur virtuel.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Partager le tunnel d'un invité avec l'hôte reflète le problème. Pointer la route par défaut de l'hôte vers l'invité fonctionne, et un proxy dans l'invité aussi ; le NAT via l'hôte ne porte pas le tunnel de l'invité pour le trafic que l'hôte a initié. Enregistrez les noms de segments et les règles de pare-feu au même endroit, prenez un instantané de l'état qui fonctionne et notez l'adresse source que le serveur a observée. Le prochain changement de profil coûte alors une exécution de script au lieu d'un laboratoire reconstruit.