VirtualBox VPN-lab: gateway-VM versus alleen-host-netwerk

U moet beslissen hoeveel machinerie uw VPN-lab verdient. Een gerouteerde gateway-VM tussen twee VirtualBox-segmenten reproduceert de adresvertaling, het retourpad en de firewallpositie waarachter een echte client zit. Eén enkel alleen-host-segment geeft u één gecontroleerde deur en niets anders. De gateway-versie kost drie gasten en een routingtabel die u onderhoudt; de alleen-host-versie kost één gast en één beleid. Drie vragen scheiden ze, en de derde bepaalt of uw test überhaupt kan slagen.

Beantwoord drie vragen voordat u iets kloont

Begin met wat de VPN-server moet waarnemen. Als de server een bronadres moet zien dat niet van de testgast is, moet iets tussen hen vertalen, en dat iets moet een router zijn die u beheert. Alleen-host-netwerken geeft de host een adapter op het segment van de gast, geen vertaler. Wanneer de gast vervolgens iets buiten moet bereiken, sluit u een NAT-adapter aan, en VirtualBox' eigen NAT-engine herschrijft de bron zonder het u te vragen.

Vraag daarna of de gast iets anders dan via de tunnel mag bereiken. Dat antwoord kiest intern of alleen-host, en het is de vraag die de meeste labbeschrijvingen overslaan. Vraag ten slotte wat er moet gebeuren als de tunnel wegvalt, want dat bepaalt beleid en niet topologie, en een lab dat alleen het gelukkige pad bewijst, heeft bijna niets getest.

Bekabel de drie rollen met interne netwerken

Gebruik drie gasten en twee benoemde segmenten, met de gateway als de enige machine die op beide een adapter heeft:

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

Er is geen aparte aanmaakstap voor een intern netwerk. De tekenreeks in --intnet1 is het segment: twee machines delen het alleen als de naam exact overeenkomt, en niets op de host is eraan gekoppeld. Juist die laatste eigenschap is de reden dat het lab schoon herhaalt, omdat de routes van de host, zijn eigen VPN-client en zijn firewall de gasten niet per ongeluk kunnen bereiken. Een intern segment heeft ook geen DHCP-server, tenzij u er een toevoegt, dus statische adressen zijn het kortste pad.

Geef de client alleen zijn WAN-adres, met een standaardgateway die naar het WAN-adres van de gateway wijst. De server krijgt een LAN-adres en gebruikt het LAN-adres van de gateway als standaardgateway. Een gast die twee adressen op één segment houdt, of een verdwaalde route naar het andere segment heeft, heeft een pad om de router heen, en de tests hieronder zullen tegen u liegen.

Ik houd een tekstbestand naast de VM-namen met de vier adressen en de twee segmentnamen, en plak het in elke shell. Weken later, wanneer een profielwijziging iets breekt, is dat bestand het verschil tussen het profiel debuggen en mijn eigen geheugen debuggen.

Kies intern of alleen-host voor het segment dat niet mag lekken

Alleen-host-modus maakt een virtuele adapter op de host zelf, meestal vboxnet0, en geeft de host een adres op het segment van de gast. Dat is handig voor beheer en fataal voor een isolatietest, omdat de host de gast nu rechtstreeks kan bereiken en elke dienst aan de hostkant een mogelijk pad wordt. Interne modus heeft helemaal geen hostadapter. De twee modi worden gemakkelijk verward in het paneel netwerkinstellingen, dus controleer het gedocumenteerde verschil in plaats van het label (zie de pagina VirtualBox-netwerkdetails).

Voor een gast die de tunnel moet gebruiken, is intern de veiligere standaard, met de gateway als enige uitgang. Als u alleen-host houdt, behandel de hostadapter dan als een beheerpad en zeg het hardop: de host mag de gast bereiken, en de gast mag de host niet als uitgang kunnen gebruiken.

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

De isolatie die u kunt bewijzen, is de isolatie die u hebt geconfigureerd. Een gast met één interne adapter, een standaardroute bij de gateway en geen NAT-adapter heeft geen pad dat de gateway omzeilt. Een gast met een alleen-host-adapter en een NAT-adapter heeft twee paden, en slechts één daarvan is het pad dat u wilde testen.

Routeer en vertaal op de gateway, en laat hem dan gesloten falen

VirtualBox stuurt niet door tussen segmenten; de gast doet dat. Met de VPN-server-VM achter de gateway schakelt u doorsturen in en vertaalt u het verkeer van de client terwijl het naar de server vertrekt:

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

Met die regel ziet de server het LAN-adres van de gateway in plaats van dat van de client, en zo ziet een echte client achter een provider-NAT eruit voor een head-end. Bewaar de sysctl-waarde in /etc/sysctl.d/ en de regel in de firewalldienst die de distributie gebruikt, anders zet een herstart het lab stil terug naar een gerouteerde maar onvertaalde toestand.

Doorsturen is geen autorisatie. Onder het standaardbeleid FORWARD met waarde ACCEPT verlaat een gast wiens standaardroute naar de gateway wijst het netwerk via de interface die de routingtabel kiest, met of zonder tunnel. Als de gateway ook een NAT-adapter voor pakketinstallaties heeft, is die adapter een werkende onversleutelde uitgang op het moment dat de tunnel wegvalt, en uw alleen-VPN-test was nooit een alleen-VPN-test.

Wanneer de server op afstand staat en de gateway zelf de tunnel beëindigt, wijst dezelfde beslissing naar de tunnelinterface, niet naar de NIC die het internet bereikt:

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

Houd het eigen buitenste transport van de tunnel en een out-of-band beheerroute gescheiden van doorgestuurd verkeer. Als de enige manier om de gateway te repareren via de tunnel loopt die u aan het debuggen bent, wordt het lab een uitsluitingsoefening. Een seriële console, een alleen-host-beheeradapter of een momentopname van een bekende goede toestand is goedkoper dan een kapotte router met de hand herstellen.

Verifieer het pad vanaf de gast, niet vanaf de host

Werk naar buiten. Bevestig dat de client het WAN-adres van de gateway bereikt, dan de server via de gateway, dan dat een verbinding naar de VPN-poort weggaat en terugkomt. Een opname op beide gateway-interfaces laat zien of het antwoord aankomt en op het retourpad wordt weggegooid, wat een opname alleen op de client niet kan onderscheiden:

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

Bewijs daarna de uitgang. Vraag vanaf de gast aan een adresreflectiedienst welk bronadres die ziet en vergelijk dat met het eigen uitgangsadres van de gateway; als het antwoord overeenkomt met het adres van de host, bestaat er een pad om de tunnel heen. Controleer welke resolver de gast werkelijk gebruikt, en controleer IPv6 apart, omdat een segment waar IPv6 aan staat terwijl de tunnel alleen IPv4 draagt, per ontwerp lekt en niet per ongeluk.

Breek het ten slotte expres. Stop de tunnel, of blokkeer zijn buitenste poort, en open een nieuwe verbinding vanaf de gast. Die moet mislukken, en de reden moet er een zijn die u kunt benoemen: geen route, een weigeringsregel of een dode resolver. Start de tunnel opnieuw en bevestig dat de gast herstelt zonder het netwerk opnieuw op te bouwen. Als een mesh-VPN zoals Hamachi of ZeroTier het lab deelt, onthoud dan dat een overbrugde adapter de adapternaam volgt, niet de mesh, dus de brug moet opnieuw worden gericht nadat de client zijn eigen virtuele adapter installeert.

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

Het delen van de tunnel van een gast met de host weerspiegelt het probleem. De standaardroute van de host naar de gast richten werkt, en een proxy in de gast ook; NAT via de host draagt de tunnel van de gast niet voor verkeer dat de host is begonnen. Bewaar de segmentnamen en de firewallregels op één plek, maak een momentopname van de werkende toestand en noteer het bronadres dat de server heeft waargenomen. De volgende profielwijziging kost dan één scriptrun in plaats van een opnieuw opgebouwd lab.