Dirigera VM-trafik på host-only-nätverket genom en TUN OpenVPN-server

Host-only-adapter skapar ett lokalt virtuellt nätverk, och routade TUN-tunnlar bär IP-paket mellan adresser. Ingen av dem är en bro till den andra, därför måste en fungerande konfiguration säga vem som vidarebefordrar och vem som äger returvägen. Blandar man ihop dessa två tilldelningar svarar gästen tunneln med en källa som tunnelklienten aldrig bad om. Designen nedan håller båda prefixen åtskilda och gör returvägen explicit.

Två nätverk, två prefix

Ge tunnelpoolen och host-only-nätverket olika prefix och använd aldrig det ena för det andra. I det här exemplet är VPN-poolen 10.44.0.0/24 och host-only-nätverket 192.168.99.0/24, med värden på 192.168.99.1 och en gäst på 192.168.99.20. Att tilldela samma prefix både till en TUN-enhet och till host-only-adaptern kopplar inte ihop dem. Det skapar två anspråk på ett adressområde, och routingtabellen svarar sedan för det anspråk den råkade behålla.

Host-only-adaptern finns på värden och inuti gästen, och den har inte av sig själv någon väg ut ur maskinen. Bryggade och NAT-anslutningar har olika exponering, och att byta till bryggat läge är inte ett krav för att nå en enda gästtjänst.

Värden har redan vägen

Titta på vad som finns innan du lägger till något. Värden har ett gränssnitt på host-only-nätverket och en rutt för det prefixet, båda skapade när adaptern kom upp.

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

Den tredje raden är mekanismen som gör värden till ett hopp. Utan den är ett paket som anländer från tunneln adresserat till ett nätverk som värden kan nå men inte kommer att vidarebefordra. Vidarebefordran är nödvändig och inte tillräcklig. Filterpolicyn avgör fortfarande om ett visst flöde mellan tunnelgränssnittet och host-only-gränssnittet är tillåtet, och det beslutet hör hemma skriftligt i stället för i en standardpolicy som ingen har läst.

Skjut ut rutten och filtrera sedan vad den når

Servern kan leverera host-only-prefixet till klienter som accepterar utskjutna rutter, vilket är samma mekanism som används för alla andra subnät bakom tunneln.

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

Dessa två regler tillåter en tjänst i en riktning och dess svar. En rutt som når hela prefixet och ett filter som tillåter en enda port är en medveten kombination; en rutt plus ett ovillkorligt accepterande är hur en labbtjänst blir en exponerad tjänst. En utskjuten rutt är inte heller någon auktorisering. Klienten accepterar den, värden vidarebefordrar den, och gästens brandvägg och tjänsten själv har fortfarande ett ord med i laget.

Gästen behöver en väg tillbaka

En gäst som nås från 10.44.0.x måste skicka sina svar till värdens host-only-adress, eller så måste värden översätta källan. Att ta emot en adress från VirtualBox DHCP säger ingenting om någon av de två ordningarna.

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

Att lägga till den rutten inuti gästen bevarar den ursprungliga källan, vilket håller policy och loggar per klient meningsfulla. Begränsad källöversättning på värden är alternativet, och det fungerar, till priset av att dölja vilken klient som anslöt. Överlappning är det andra felfallet. En fjärrklient vars hemma-LAN redan använder 192.168.99.0/24 kommer att läsa den utskjutna rutten som sitt eget nätverk, och ingen ändring på serversidan rättar till den tvetydigheten. Numrera om en sida eller välj ett prefix som sannolikt inte krockar.

En TUN-enhet bär IP-paket, så att lägga till en standardgateway inuti en gäst gör inte tunneln till ett Ethernet-segment med host-only-adaptern. TAP-brygga är en annan design med sitt eget klientstöd och adressägande, och att blanda de två beskrivningarna leder till konfigurationer som aldrig konvergerar.

Verifiera och gör det sedan motståndskraftigt mot en omstart

Testa en ofarlig tjänst från en vanlig fjärrklient, kontrollera gästens returväg och bekräfta att en tjänst du inte tillät avvisas i stället för att vara långsam.

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

Starta sedan om VPN-tjänsten och den virtuella maskinens nätverk, och upprepa samma tre kontroller. En rutt som lagts till för hand överlever till nästa omstart, och en konfiguration som bara fungerar i en varm session är inte en design. Skriv ner de två prefixen, vidarebefordringspolicyn och gästens rutt tillsammans. Den som lägger till nästa virtuella maskin behöver alla tre och kommer annars att upptäcka dem på nytt en misslyckad anslutning i taget.