Rut VM-trafik på host-only-netværket gennem en TUN OpenVPN-server

Host-only-adaptere opretter et lokalt virtuelt netværk, og rutede TUN-tunneler bærer IP-pakker mellem adresser. Ingen af dem er en bro til den anden, og derfor skal en fungerende konfiguration sige, hvem der videresender, og hvem der ejer returruten. Tager man disse to tildelinger fejl, svarer gæsten tunnelen med en kilde, som tunnelklienten aldrig bad om. Designet nedenfor holder begge præfikser adskilt og gør returvejen eksplicit.

To netværk, to præfikser

Giv tunnelpoolen og host-only-netværket forskellige præfikser, og genbrug aldrig det ene til det andet. I dette eksempel er VPN-poolen 10.44.0.0/24 og host-only-netværket 192.168.99.0/24, med værten på 192.168.99.1 og en gæst på 192.168.99.20. At tildele det samme præfiks til både en TUN-enhed og host-only-adapteren forbinder dem ikke. Det skaber to krav på ét adresseområde, og routingtabellen svarer derefter for det krav, den tilfældigt beholdt.

Host-only-adapteren findes på værten og inde i gæsten, og den har ikke i sig selv en vej ud af maskinen. Bro- og NAT-tilslutninger har forskellig eksponering, og det er ikke et krav at skifte til bro-tilstand for at nå én gæstetjeneste.

Værten har allerede ruten

Se på, hvad der findes, før du tilføjer noget. Værten har et interface på host-only-netværket og en rute for det præfiks, begge oprettet da adapteren kom op.

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

Den tredje linje er mekanismen, der gør værten til et hop. Uden den er en pakke, der ankommer fra tunnelen, adresseret til et netværk, som værten kan nå, men ikke vil videresende til. Videresendelse er nødvendig og ikke tilstrækkelig. Filterpolitikken afgør stadig, om en bestemt strøm mellem tunnelinterfacet og host-only-interfacet er tilladt, og den beslutning hører til på skrift i stedet for i en standardpolitik, som ingen har læst.

Push ruten, og filtrer derefter, hvad den når

Serveren kan levere host-only-præfikset til klienter, der accepterer push'ede ruter, hvilket er samme mekanisme som for ethvert andet subnet bag tunnelen.

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

De to regler tillader én tjeneste i én retning og dens svar. En rute, der når hele præfikset, og et filter, der tillader én port, er en bevidst kombination; en rute plus en ubetinget accept er måden, hvorpå en laboratorietjeneste bliver en eksponeret tjeneste. En push'et rute er heller ikke autorisation. Klienten accepterer den, værten videresender den, og gæstens firewall og tjenesten selv har stadig en stemme.

Gæsten har brug for en vej tilbage

En gæst, der nås fra 10.44.0.x, skal sende sine svar til værtens host-only-adresse, eller værten skal oversætte kilden. At modtage en adresse fra VirtualBox DHCP siger intet om nogen af de to arrangementer.

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

At tilføje den rute inde i gæsten bevarer den oprindelige kilde, hvilket holder politik og logfiler for hver klient meningsfulde. Afgrænset kildeoversættelse på værten er alternativet, og det virker, men på bekostning af at skjule, hvilken klient der blev forbundet. Overlap er den anden fejltilstand. En fjernklient, hvis hjemme-LAN allerede bruger 192.168.99.0/24, vil læse den push'ede rute som sit eget netværk, og ingen ændring på serversiden retter den tvetydighed. Omnummerér den ene side, eller vælg et præfiks, der næppe kolliderer.

En TUN-enhed bærer IP-pakker, så det at tilføje en standardgateway inde i en gæst gør ikke tunnelen til et Ethernet-segment sammen med host-only-adapteren. TAP-bridging er et andet design med sin egen klientunderstøttelse og adresseejerskab, og at blande de to beskrivelser fører til konfigurationer, der aldrig konvergerer.

Verificér, og gør det så modstandsdygtigt over for en genstart

Test én uskadelig tjeneste fra en almindelig fjernklient, kontrollér gæstens returrute, og bekræft, at en tjeneste, du ikke tillod, afvises i stedet for at være langsom.

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

Genstart derefter VPN-tjenesten og den virtuelle maskines netværk, og gentag de samme tre kontroller. En rute, der er tilføjet i hånden, overlever indtil næste genstart, og en konfiguration, der kun virker i en varm session, er ikke et design. Skriv de to præfikser, videresendelsespolitikken og gæstens rute ned sammen. Den, der tilføjer den næste virtuelle maskine, får brug for alle tre og vil ellers genopdage dem én mislykket forbindelse ad gangen.