Rut VM-trafikk på host-only-nettverket gjennom en TUN OpenVPN-server

Host-only-adaptere lager et lokalt virtuelt nettverk, og rutede TUN-tunneler bærer IP-pakker mellom adresser. Ingen av dem er en bro til den andre, derfor må en fungerende konfigurasjon si hvem som videresender og hvem som eier returruten. Tar man disse to tildelingene feil, svarer gjesten tunnelen med en kilde som tunnelklienten aldri ba om. Designet nedenfor holder begge prefiksene atskilt og gjør returveien eksplisitt.

To nettverk, to prefikser

Gi tunnelpoolen og host-only-nettverket forskjellige prefikser og bruk aldri det ene for det andre. I dette eksempelet 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 en gjest på 192.168.99.20. Å tildele samme prefiks til både en TUN-enhet og host-only-adapteren kobler dem ikke sammen. Det skaper to krav på ett adresseområde, og rutingtabellen svarer deretter for det kravet den tilfeldigvis beholdt.

Host-only-adapteren finnes på verten og inne i gjesten, og den har ikke i seg selv en vei ut av maskinen. Bro- og NAT-tilkoblinger har ulik eksponering, og det er ikke et krav å bytte til bromodus for å nå én gjestetjeneste.

Verten har allerede ruten

Se på hva som finnes før du legger til noe. Verten har et grensesnitt på host-only-nettverket og en rute for det prefikset, begge opprettet da adapteren kom opp.

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

Den tredje linjen er mekanismen som gjør verten til et hopp. Uten den er en pakke som ankommer fra tunnelen adressert til et nettverk som verten kan nå, men ikke vil videresende til. Videresending er nødvendig og ikke tilstrekkelig. Filterpolitikken avgjør fortsatt om en bestemt strøm mellom tunnelgrensesnittet og host-only-grensesnittet er tillatt, og den beslutningen hører hjemme skriftlig i stedet for i en standardpolitikk som ingen har lest.

Dytt ruten, og filtrer deretter hva den når

Serveren kan levere host-only-prefikset til klienter som godtar dyttede ruter, som er samme mekanisme som for ethvert annet 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

Disse to reglene tillater én tjeneste i én retning og svarene dens. En rute som når hele prefikset og et filter som tillater én port, er en bevisst kombinasjon; en rute pluss en ubetinget aksept er måten en laboratorietjeneste blir en eksponert tjeneste. En dyttet rute er heller ikke autorisasjon. Klienten godtar den, verten videresender den, og gjestens brannmur og tjenesten selv har fortsatt et ord med i laget.

Gjesten trenger en vei tilbake

En gjest som nås fra 10.44.0.x, må sende svarene sine til vertens host-only-adresse, eller verten må oversette kilden. Å motta en adresse fra VirtualBox DHCP sier ingenting om noen av de to ordningene.

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

Å legge til den ruten inne i gjesten bevarer den opprinnelige kilden, noe som holder politikk og logger per klient meningsfulle. Begrenset kildeoversettelse på verten er alternativet, og det virker, men på bekostning av å skjule hvilken klient som koblet til. Overlapp er den andre feilmodusen. En fjernklient hvis hjemme-LAN allerede bruker 192.168.99.0/24, vil lese den dyttede ruten som sitt eget nettverk, og ingen endring på serversiden retter opp den tvetydigheten. Omnummerer den ene siden eller velg et prefiks som neppe kolliderer.

En TUN-enhet bærer IP-pakker, så det å legge til en standard gateway inne i en gjest gjør ikke tunnelen til et Ethernet-segment sammen med host-only-adapteren. TAP-bro er et annet design med sin egen klientstøtte og adresseeierskap, og å blande de to beskrivelsene fører til konfigurasjoner som aldri konvergerer.

Verifiser, og gjør det deretter motstandsdyktig mot en omstart

Test én ufarlig tjeneste fra en vanlig fjernklient, kontroller gjestens returrute, og bekreft at en tjeneste du ikke tillot, avvises i stedet for å være treg.

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

Start deretter VPN-tjenesten og nettverket til den virtuelle maskinen på nytt, og gjenta de samme tre kontrollene. En rute som er lagt til for hånd, overlever til neste omstart, og en konfigurasjon som bare virker i en varm økt, er ikke et design. Skriv ned de to prefiksene, videresendingspolitikken og gjestens rute sammen. Den som legger til den neste virtuelle maskinen, trenger alle tre og vil ellers gjenoppdage dem én mislykket tilkobling om gangen.