VM-verkeer op het host-only-netwerk routeren via een TUN OpenVPN-server

Host-only-adapters maken een lokaal virtueel netwerk, en gerouteerde TUN-tunnels dragen IP-pakketten tussen adressen. Geen van beide is een brug naar de andere, daarom moet een werkende configuratie zeggen wie doorstuurt en van wie de terugroute is. Verwisselt u die twee toewijzingen, dan antwoordt de gast de tunnel met een bron waar de tunnelclient nooit om vroeg. Het ontwerp hieronder houdt beide prefixen gescheiden en maakt de terugweg expliciet.

Twee netwerken, twee prefixen

Geef de tunnelpool en het host-only-netwerk verschillende prefixen en gebruik er nooit één voor het andere. In dit voorbeeld is de VPN-pool 10.44.0.0/24 en het host-only-netwerk 192.168.99.0/24, met de host op 192.168.99.1 en een gast op 192.168.99.20. Hetzelfde prefix toewijzen aan zowel een TUN-apparaat als de host-only-adapter verbindt ze niet. Het maakt twee aanspraken op één adresbereik, en de routingtabel antwoordt dan voor de aanspraak die hij toevallig behield.

De host-only-adapter bestaat op de host en in de gast, en hij heeft uit zichzelf geen weg van de machine af. Bridged- en NAT-verbindingen hebben een andere blootstelling, en overschakelen naar bridged modus is geen vereiste om één gastdienst te bereiken.

De host heeft de route al

Kijk wat er bestaat voordat u iets toevoegt. De host heeft een interface op het host-only-netwerk en een route voor dat prefix, beide gemaakt toen de adapter opkwam.

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

De derde regel is het mechanisme dat de host tot een hop maakt. Zonder die regel is een pakket dat uit de tunnel komt geadresseerd aan een netwerk dat de host kan bereiken maar niet zal doorsturen. Doorsturen is nodig en niet voldoende. Het filterbeleid beslist nog steeds of een bepaalde stroom tussen de tunnelinterface en de host-only-interface is toegestaan, en die beslissing hoort op schrift in plaats van in een standaardbeleid dat niemand heeft gelezen.

Push de route en filter daarna wat hij bereikt

De server kan het host-only-prefix leveren aan clients die gepushte routes accepteren, wat hetzelfde mechanisme is als voor elk ander subnet achter de 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

Die twee regels staan één dienst in één richting en zijn antwoorden toe. Een route die het hele prefix bereikt en een filter dat één poort toestaat zijn een bewuste combinatie; een route plus een onvoorwaardelijke acceptatie is hoe een labdienst een blootgestelde dienst wordt. Een gepushte route is ook geen autorisatie. De client accepteert hem, de host stuurt hem door, en de firewall van de gast en de dienst zelf hebben nog steeds een stem.

De gast heeft een weg terug nodig

Een gast die vanaf 10.44.0.x wordt bereikt, moet zijn antwoorden naar het host-only-adres van de host sturen, of de host moet de bron vertalen. Een adres van VirtualBox DHCP ontvangen zegt niets over een van beide regelingen.

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

Die route in de gast toevoegen behoudt de oorspronkelijke bron, wat beleid en logs per client betekenisvol houdt. Beperkte bronvertaling op de host is het alternatief, en het werkt, tegen de prijs dat het verbergt welke client verbond. Overlap is de andere faalmodus. Een externe client wiens thuis-LAN al 192.168.99.0/24 gebruikt, leest de gepushte route als zijn eigen netwerk, en geen enkele wijziging aan de serverkant lost die dubbelzinnigheid op. Hernummer één kant of kies een prefix dat waarschijnlijk niet botst.

Een TUN-apparaat draagt IP-pakketten, dus een standaardgateway in een gast toevoegen maakt de tunnel niet tot een Ethernet-segment met de host-only-adapter. TAP-bridging is een ander ontwerp met zijn eigen clientondersteuning en adresbeheer, en het mengen van de twee beschrijvingen leidt tot configuraties die nooit convergeren.

Verifieer en maak het daarna bestand tegen een herstart

Test één onschadelijke dienst vanaf een gewone externe client, controleer de terugroute van de gast en bevestig dat een dienst die u niet hebt toegestaan wordt geweigerd in plaats van traag.

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

Herstart daarna de VPN-dienst en de netwerkinstellingen van de virtuele machine, en herhaal dezelfde drie controles. Een met de hand toegevoegde route overleeft tot de volgende herstart, en een configuratie die alleen in een warme sessie werkt is geen ontwerp. Leg de twee prefixen, het doorstuurbeleid en de route van de gast samen vast. Wie de volgende virtuele machine toevoegt, heeft alle drie nodig en zal ze anders één mislukte verbinding na de andere opnieuw ontdekken.