Ferkeer fan VM's op it host-only-netwurk oer in TUN-OpenVPN-tsjinner liede

Host-only-adapters meitsje in pleatslik firtueel netwurk, en rûtele TUN-tunnels drage IP-pakketten tusken adressen. Gjin fan beide is in brêge nei de oare, dêrom moat in wurkjende konfiguraasje sizze wa't trochstjoert en wa't de weromrûte hat. Gean dy twa tawizings ferkeard, dan antwurdet de gast de tunnel mei in boarne dêr't de tunnelkliïnt nea om frege hat. It ûntwerp hjirûnder hâldt beide foarheaksels skieden en makket de weromwei eksplisyt.

Twa netwurken, twa foarheaksels

Jou de tunnelpool en it host-only-netwurk ferskillende foarheaksels en brûk nea de iene foar de oare. Yn dit foarbyld is de VPN-pool 10.44.0.0/24 en it host-only-netwurk 192.168.99.0/24, mei de host op 192.168.99.1 en in gast op 192.168.99.20. Deselde foarheaksel oan sawol in TUN-apparaat as de host-only-adapter jaan, ferbynt se net. It makket twa oanspraken op ien adresberik, en de rûtetabel antwurdet dan foar de oanspraak dy't er tafallich hold.

De host-only-adapter bestiet op 'e host en yn 'e gast, en hy hat fan himsels gjin wei fan 'e masine ôf. Brêge- en NAT-oanslutingen hawwe in oare bleatstelling, en oerstappe nei brêgemodus is gjin betingst om ien gasttsjinst te berikken.

De host hat de wei al

Sjoch wat der is foardat jo wat tafoegje. De host hat in ynterface op it host-only-netwurk en in rûte foar dat foarheaksel, beide oanmakke doe't de adapter omheech kaam.

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

De tredde rigel is it meganisme dat de host in hop makket. Sûnder dy is in pakket dat út 'e tunnel komt adressearre oan in netwurk dat de host berikke kin mar net trochstjoere sil. Trochstjoeren is needsaaklik en net genôch. It filterbelied beslúdt noch altyd oft in beskaat stream tusken it tunnel-ynterface en it host-only-ynterface tastien is, en dat beslút heart skriftlik, net yn in standertbelied dat nimmen lêzen hat.

Triuw de rûte, filterje dan wat er berikt

De tsjinner kin it host-only-foarheaksel oan klanten leverje dy't triuwde rûtes akseptearje, dat is itselde meganisme as foar elk oar subnet efter de tunnel.

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

Dy twa regels tastean ien tsjinst yn ien rjochting en har antwurden. In rûte dy't it hiele foarheaksel berikt en in filter dat ien poarte tastiet binne in bewuste kombinaasje; in rûte plus in sûnder betingsten akseptearjen is hoe't in laboratoariumtsjinst in bleatstelde tsjinst wurdt. In triuwde rûte is ek gjin autorisaasje. De kliïnt akseptearret it, de host stjoert it troch, en de gastfirewall en de tsjinst sels hawwe noch in stim.

De gast hat in wei werom nedich

In gast dy't fan 10.44.0.x berikt wurdt, moat syn antwurden nei it host-only-adres fan 'e host stjoere, of de host moat de boarne oersette. In adres fan VirtualBox DHCP krije seit neat oer ien fan beide regelingen.

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

Dy rûte yn 'e gast tafoegje behâldt de oarspronklike boarne, wat belied en logboeken per kliïnt betsjuttingsfol hâldt. Beheinde boarneoersetting op 'e host is it alternatyf, en it wurket, tsjin de priis fan ferbergjen hokker kliïnt ferbûn wie. Oerlap is de oare falmodus. In ôfstiene kliïnt waans thús-LAN al 192.168.99.0/24 brûkt, sil de triuwde rûte as syn eigen netwurk lêze, en gjin feroaring oan 'e tsjinnerkant reparearret dy dûbelsinnigens. Nûmerje ien kant opnij of kies in foarheaksel dat wierskynlik net botskiet.

In TUN-apparaat draacht IP-pakketten, dus in standertgateway yn 'e gast tafoegje makket de tunnel net in Ethernet-segmint mei de host-only-adapter. TAP-brêgjen is in oar ûntwerp mei syn eigen kliïntstipe en adresbesit, en it mingen fan 'e twa beskriuwings liedt ta konfiguraasjes dy't nea konvergearje.

Ferifiearje, en meitsje it dan bestindich tsjin in werstart

Test ien ûnskealik tsjinst fan in gewoane ôfstiene kliïnt, kontrolearje de weromrûte fan 'e gast, en befêstigje dat in tsjinst dy't jo net tastien hawwe wegere wurdt ynstee fan stadich.

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

Werstart dan de VPN-tsjinst en it netwurk fan 'e firtuele masine, en werhelje deselde trije kontrôles. In rûte dy't mei de hân tafoege is, oerlibbet oant de folgjende werstart, en in konfiguraasje dy't allinnich yn in waarme sessy wurket is gjin ûntwerp. Skriuw de twa foarheaksels, it trochstjoerbelied en de rûte fan 'e gast byinoar. Wa't de folgjende firtuele masine tafoeget, hat alle trije nedich en sil se oars ien mislearre ferbining nei de oare weromfine.