Rut VM-trafikk på host-only-nettverket gjennom ein TUN OpenVPN-tenar

Host-only-adapterar lagar eit lokalt virtuelt nettverk, og ruta TUN-tunnelar ber IP-pakkar mellom adresser. Ingen av dei er ei bru til den andre, difor må ein konfigurasjon som verkar seie kven som videresender og kven som eig returruta. Tek ein desse to tildelingane feil, svarar gjesten tunnelen med ei kjelde som tunnelklienten aldri bad om. Designet nedanfor held begge prefiksa åtskilde og gjer returvegen eksplisitt.

To nettverk, to prefiks

Gje tunnelpoolen og host-only-nettverket ulike prefiks og bruk aldri det eine for det andre. I dette dømet er VPN-poolen 10.44.0.0/24 og host-only-nettverket 192.168.99.0/24, med verten på 192.168.99.1 og ein gjest på 192.168.99.20. Å gje same prefiks både til eit TUN-utstyr og til host-only-adapteren knyter dei ikkje saman. Det lagar to krav på eitt adresseområde, og rutetabellen svarar deretter for det kravet han tilfeldigvis behheldt.

Host-only-adapteren finst på verten og inne i gjesten, og han har ikkje i seg sjølv ein veg ut av maskina. Bru- og NAT-tilkoplingar har ulik eksponering, og det er ikkje eit krav å byte til brumodus for å nå éin gjesteteneste.

Verten held allereie ruta

Sjå på kva som finst før du legg til noko. Verten har eit grensesnitt på host-only-nettverket og ei rute for det prefikset, begge laga då adapteren kom opp.

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

Den tredje lina er mekanismen som gjer verten til eit hopp. Utan han er ein pakke som kjem frå tunnelen adressert til eit nettverk som verten kan nå, men ikkje vil videresende til. Videresending er naudsynt og ikkje tilstrekkeleg. Filterpolitikken avgjer framleis om ein bestemd straum mellom tunnelgrensesnittet og host-only-grensesnittet er tillaten, og den avgjerda høyrer heime skriftleg i staden for i ein standardpolitikk som ingen har lese.

Dytt ruta, og filtrer deretter kva ho når

Tenaren kan levere host-only-prefikset til klientar som godtek dytta ruter, som er same mekanismen som for eit kva som helst anna subnett bak 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

Desse to reglane tillèt éi teneste i éi retning og svara hennar. Ei rute som når heile prefikset og eit filter som tillèt éin port, er ein medviten kombinasjon; ei rute pluss ei ubetinga godkjenning er måten ei laboratorieteneste blir ei open teneste. Ei dytta rute er heller ikkje autorisasjon. Klienten godtek ho, verten videresender ho, og brannmuren til gjesten og tenesta sjølv har framleis eit ord med i laget.

Gjesten treng ein veg tilbake

Ein gjest som blir nådd frå 10.44.0.x, må sende svara sine til host-only-adressa til verten, eller verten må omsetje kjelda. Å ta imot ei adresse frå VirtualBox DHCP seier ingenting om nokon av dei to ordningane.

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

Å leggje til den ruta inne i gjesten bevarar den opphavlege kjelda, noko som held politikk og loggar per klient meiningsfulle. Avgrensa kjeldeomsetjing på verten er alternativet, og det verkar, men på kostnad av å skjule kva klient som kopla til. Overlapp er den andre feilmodusen. Ein fjernklient som heime-LAN-et hans allereie brukar 192.168.99.0/24, vil lese den dytta ruta som sitt eige nettverk, og inga endring på tenarsida rettar opp den tvitydigheita. Omnummerer den eine sida eller vel eit prefiks som neppe kolliderer.

Eit TUN-utstyr ber IP-pakkar, så det å leggje til ein standard gateway inne i ein gjest gjer ikkje tunnelen til eit Ethernet-segment saman med host-only-adapteren. TAP-bru er eit anna design med si eiga klientstøtte og eige adresseeige, og å blande dei to skildringane fører til konfigurasjonar som aldri konvergerer.

Stadfest, og gjer det deretter motstandsdyktig mot ein omstart

Test éi ufarleg teneste frå ein vanleg fjernklient, kontroller returruta til gjesten, og stadfest at ei teneste du ikkje tillét, blir avvist i staden for å vere treg.

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

Start deretter VPN-tenesta og nettverket til den virtuelle maskina på nytt, og repetér dei same tre kontrollane. Ei rute som er lagd til for hand, overlever til neste omstart, og ein konfigurasjon som berre verkar i ei varm økt, er ikkje eit design. Skriv ned dei to prefiksa, videresendingspolitikken og ruta til gjesten saman. Den som legg til den neste virtuelle maskina, treng alle tre og vil elles oppdage dei på nytt éin mislukka tilkopling om gongen.