Usmerjanje prometa VM v omrežju host-only prek strežnika TUN OpenVPN
Tunel in predpono host-only držite ločeno, potisnite pot gosta in nato vsaki virtualni napravi dajte namerno pot nazaj skozi gostitelja.
Vmesniki host-only ustvarijo lokalno virtualno omrežje, usmerjeni tuneli TUN pa prenašajo pakete IP med naslovi. Nobeden od njiju ni most do drugega, zato mora delujoča konfiguracija povedati, kdo posreduje in čigava je pot nazaj. Če ti dve dodelitvi zamenjate, gost tunelu odgovori z virom, ki ga odjemalec tunela ni nikoli zahteval. Spodnja zasnova ohranja obe predponi ločeni in naredi pot nazaj izrecno.
Dve omrežji, dve predponi
Dajte bazenu tunela in omrežju host-only različni predponi in nikoli ne uporabite ene namesto druge. V tem primeru je bazen VPN 10.44.0.0/24, omrežje host-only pa 192.168.99.0/24, gostitelj je na 192.168.99.1, gost pa na 192.168.99.20. Dodelitev iste predpone tako napravi TUN kot vmesniku host-only ju ne poveže. Ustvari dve zahtevi za eno območje naslovov in usmerjevalna tabela se nato odzove za tisto zahtevo, ki jo je slučajno obdržala.
Vmesnik host-only obstaja na gostitelju in znotraj gosta, in sam po sebi nima poti iz naprave. Mostni in NAT priključki imajo drugačno izpostavljenost, preklop v mostni način pa ni pogoj za dosego ene storitve gosta.
Gostitelj že drži pot
Poglejte, kaj obstaja, preden kaj dodate. Gostitelj ima vmesnik v omrežju host-only in pot za to predpono, oba ustvarjena ob dvigu vmesnika.
ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward
Tretja vrstica je mehanizem, ki gostitelja spremeni v skok. Brez njega je paket, ki prispe iz tunela, naslovljen na omrežje, ki ga gostitelj doseže, a ga ne bo posredoval. Posredovanje je potrebno in ni dovolj. Pravilo filtriranja še vedno odloča, ali je določen tok med vmesnikom tunela in vmesnikom host-only dovoljen, in ta odločitev sodi pisno, ne v privzeto pravilo, ki ga nihče ni prebral.
Potisnite pot in nato filtrirajte, kaj doseže
Strežnik lahko predpono host-only zagotovi odjemalcem, ki sprejemajo potisnjene poti, kar je isti mehanizem kot za katero koli drugo podomrežje za tunelom.
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
Ti dve pravili dovolita eno storitev v eni smeri in njene odgovore. Pot, ki doseže celotno predpono, in filter, ki dovoli ena vrata, sta namerna kombinacija; pot plus brezpogojno sprejetje je način, kako laboratorijska storitev postane izpostavljena. Potisnjena pot tudi ni dovoljenje. Odjemalec jo sprejme, gostitelj jo posreduje, požarni zid gosta in storitev sama pa imata še vedno besedo.
Gost potrebuje pot nazaj
Gost, do katerega se pride z 10.44.0.x, mora svoje odgovore pošiljati na naslov host-only gostitelja, ali pa mora gostitelj prevesti vir. Prejem naslova od DHCP VirtualBox ne pove ničesar o nobeni od obeh ureditev.
ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15
Dodajanje te poti znotraj gosta ohrani prvotni vir, kar ohranja smiselno pravilo in dnevnike na odjemalca. Omejeno prevajanje vira na gostitelju je alternativa in deluje, a za ceno skrivanja, kateri odjemalec se je povezal. Prekrivanje je drugi način odpovedi. Oddaljeni odjemalec, katerega domače omrežje LAN že uporablja 192.168.99.0/24, bo potisnjeno pot bral kot svoje omrežje, in nobena sprememba na strani strežnika te dvoumnosti ne odpravi. Preštevilčite eno stran ali izberite predpono, ki verjetno ne bo v nasprotju.
Naprava TUN prenaša pakete IP, zato dodajanje privzetih vrat znotraj gosta tunela ne spremeni v segment Ethernet z vmesnikom host-only. Most TAP je drugačna zasnova z lastno podporo odjemalcem in lastništvom naslovov, mešanje obeh opisov pa vodi v konfiguracije, ki se nikoli ne približajo.
Preverite in nato poskrbite, da bo prestalo ponovni zagon
Preizkusite eno neškodljivo storitev z običajnega oddaljenega odjemalca, preverite pot nazaj gosta in potrdite, da je storitev, ki je niste dovolili, zavrnjena in ne počasna.
ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20
Nato znova zaženite storitev VPN in omrežje virtualne naprave ter ponovite iste tri preveritve. Pot, dodana ročno, preživi do naslednjega zagona, konfiguracija, ki deluje le v topli seji, pa ni zasnova. Zapišite obe predponi, pravilo posredovanja in pot gosta skupaj. Kdor doda naslednjo virtualno napravo, bo potreboval vse tri, sicer jih bo znova odkrival eno neuspešno povezavo za drugo.