VirtualBox NAT of brêge: wêr't de VPN fan 'e VM einiget

Twa ferskate fragen komme tagelyk as in firtuele masine in VPN-klant útfiert, en se hawwe ferskate antwurden. De earste is oft in tunnel yn 'e gast de host beskermet, en de twadde is oft in tunnel op 'e host de gast dekt. De adaptermodus beslút beide, mear as de VPN-software sels. In NAT-adapter makket de host it sichtbere einpunt, wylst in brêge-adapter de gast mei syn eigen adres op it net set.

Wa't de fersifere sesje eins beëiniget

In fersifere sesje heart by de masine dy't him beëiniget, en dat is de gast as de klant yn 'e VM draait. Allinnich ferkear dat yn 'e firtuele adapter fan 'e gast komt giet troch dy tunnel, en de hypervisor liedt nea in oare masine troch de gast op syn eigen inisjatyf. Dêrom kin de gast in wurkjende tunnel hâlde wylst de host iepen op it net sjocht. It omkearde is net symmetrysk, en dy asymmetry is it part dat de measte hantliedingen ferkeard hawwe.

Hokker adres it bûtennet sjocht is de fraach dy't de adaptermodus beantwurdet. As dat besletten is, hâldt dekking op in beliedsfraach te wêzen en wurdt it in meganyske. Alles hjirûnder folget út dy twa feiten.

NAT skriuwt de gast om oant er op 'e host liket

By NAT skriuwt de hypervisor elk pakket fan 'e gast om nei it adres fan 'e host foardat it de earste skakelaar berikt. Dat ferkear wurdt dan oan 'e eigen netwurkstapel fan 'e host jûn, dêr't it syn rûtingstabel folget, ynklusyf in standertrûte dy't eigendom is fan in tunnel op 'e host. In NAT-gast wurdt dêrom sûnder hokker konfiguraasje dan ek troch in tunnel op 'e host dekt, wat it tsjinoerstelde is fan wat it gefal fan gast nei host suggerearret.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

In gast dy't syn eigen klant draait, beëiniget dy tunnel yn 'e gast, en it fersifere ferkear giet dan troch deselde omskriuwing nei bûten, sadat tapassingen fan 'e host har eigen paad en har eigen útgongsadres hâlde. VirtualBox hat yn dizze modus ek it namme-oplossen, en stjoert fragen fan 'e gast troch syn eigen motor, útsein as --natdnshostresolver1 oan stiet. It oansetten jout de sykaksjes fan 'e gast oan 'e resolver fan 'e host, wat it oplossen reparearret wannear't it eigen byld fan 'e host goed is en likegoed in resolver jout dy't miskien allinnich yn in tunnel bestiet. De VM moat útskeakele wêze foardat de ynstelling feroaret, en de ynstelling heart by de adapter en net by de software fan 'e gast.

In brêge jout de gast syn eigen lease en syn eigen bleatstelling

In brêge jout de frames fan 'e gast troch nei it fysike segmint, dus DHCP jout him in lease en it net behannelet him as in aparte host. Eltse oerbrêge gast kin in ûnôfhinklike tunnel hâlde mei syn eigen standertrûte, en de tabel fan 'e host feroaret nea. De priis is bleatstelling: de gast antwurdet op útstjoerings, ferskynt yn buerttabellen en komt ûnder poartesekuerens fan 'e skakelaar en isolaasje fan draadleaze klanten. In tunnel op 'e host dekt dizze opstelling ek net, want frames fan 'e gast geane nea troch de stapel fan 'e host.

Dat ferskil mei it NAT-gefal is wurdich om gewoan te sizzen ynstee fan it as in ymplikaasje te litten. In oerbrêge gast hat syn eigen klant en syn eigen oanmeldgegevens nedich as syn ferkear in tunnel brûke moat. Wêr't de gast ûnsichtber bliuwe moat foar it lokale net, is NAT of in net allinnich foar binnenlânsk gebrûk mei kontrolearre rûting it bettere ûntwerp.

Wêrom't de gast de gateway fan 'e host net wêze kin

It lienen fan 'e tunnel fan in gast oan 'e host hat gjin stipe skakelaar yn ien fan 'e beide grutte hypervisors. De host hat gjin rûte yn 'e tunnel fan 'e gast en gjin oersettingsregel dy't dêrhinne wiist, dus ferkear fan gast en host bliuwt aparte streamen mei aparte eigners. Dy rjochting mislearret los fan 'e adaptermodus.

De wurkbere ferfangers binne trochstjoerings en proxies. In lokale SSH-trochstjoering lit de host ferbine mei syn eigen loopback wylst de gast de stream de tunnel yn draacht, wat TCP-tsjinsten dekt sûnder in twadde klant te ynstallearjen. It eigen IP-ferkear fan 'e host ynstee de tunnel fan 'e gast brûke litte freget in router yn 'e gast plus in eksplisite rûte op 'e host en oersetting op 'e host. Dat is in lyts netûntwerp en gjin oanfinkfak, en it freget in plan foar de weromwei. As de gast allinnich bestiet om de klant te draaien, set de klant dan op 'e host en skras de ekstra hop.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Resolvers en rûtes oerstekke de grins net

DNS folget de adapter dy't de opsje ûntfongen hat, dus in gast erft de tunnelresolver fan 'e host net en in host leart nea de tsjinner dy't nei de gast ta skood is. Skode wearden fan dhcp-option DNS jilde foar de ynterface dy't se akseptearre hat, en dêrom kin in oerbrêge gast sûnder klant gjin ynterne nammen oplosse. In NAT-gast brûkt meastentiids ynstee de DNS-behanneling fan 'e hypervisor, en it ferskil is te sjen yn ien opdracht per omjouwing.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Lês de resolver en de rûte yn 'e gast foardat do oannimst dat ien fan beide de host folget. Foegje de tunnelresolver ta oan 'e eigen adapter fan 'e gast as ynterne nammen dêr oplost wurde moatte, en kontrolearje dan mei in namme dy't allinnich efter de tunnel bestiet. Skriuw de adaptermodus, de eigner fan 'e tunnel en de boarne fan 'e resolver foar elke VM op, want dy trije feiten beäntwurdzje hast elke lettere fraach. Oare hypervisors neame de modi oars en litte it prinsipe yntakt.