VirtualBox NAT vai silta: mihin VM:n VPN päättyy

Kaksi eri kysymystä saapuu yhdessä aina, kun virtuaalikone käynnistää VPN-asiakkaan, ja niillä on eri vastaukset. Ensimmäinen on, suojaako vieraan sisällä oleva tunneli isäntää, ja toinen on, kattaako isännällä oleva tunneli vieraan. Sovittimen tila ratkaisee molemmat, enemmän kuin VPN-ohjelmisto itse. NAT-sovitin tekee isännästä näkyvän päätepisteen, kun taas siltaava sovitin asettaa vieraan verkkoon omalla osoitteellaan.

Kuka salatun istunnon oikeasti päättää

Salattu istunto kuuluu koneelle, joka sen päättää, ja se on vieras, kun asiakas toimii VM:n sisällä. Tunnelista kulkee vain liikenne, joka saapuu vieraan virtuaalisovittimeen, eikä hypervisori koskaan reititä toista konetta vieraan kautta omasta aloitteestaan. Siksi vieras voi pitää toimivan tunnelin, kun isäntä selaa avoimessa verkossa. Käänteinen ei ole symmetrinen, ja juuri tämä epäsymmetria on se osa, jonka useimmat oppaat ymmärtävät väärin.

Minkä osoitteen ulkoverkko näkee, on kysymys, johon sovittimen tila vastaa. Kun se on selvitetty, kattavuus lakkaa olemasta politiikkakysymys ja muuttuu mekaaniseksi. Kaikki alla seuraa näistä kahdesta tosiasiasta.

NAT kirjoittaa vieraan uudelleen, kunnes se näyttää isännältä

NATissa hypervisori kirjoittaa jokaisen vieraan paketin isännän osoitteeseen ennen kuin se saavuttaa ensimmäisen kytkimen. Tämä liikenne luovutetaan sitten isännän omalle verkkopinolle, jossa se noudattaa isännän reititystaulukkoa, mukaan lukien oletusreittiä, joka kuuluu isännällä olevalle tunnelille. NAT-vieras on siis isännän tunnelin kattama ilman mitään konfiguraatiota, mikä on päinvastoin kuin vieras-isäntä-tapaus antaa ymmärtää.

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

Vieras, joka ajaa omaa asiakastaan, päättää tunnelin vieraan sisällä, ja salattu liikenne lähtee sitten saman uudelleenkirjoituksen kautta, joten isännän sovellukset pitävät oman polkunsa ja oman lähtöosoitteensa. VirtualBox omistaa tässä tilassa myös nimien selvityksen ja välittää vieraan kyselyt oman moottorinsa kautta, ellei --natdnshostresolver1 ole käytössä. Sen käyttöönotto antaa vieraan haut isännän selvittimelle, mikä korjaa selvityksen, kun isännän oma näkemys on oikea, ja yhtä lailla luovuttaa selvittimen, joka voi olla olemassa vain tunnelin sisällä. VM on sammutettava ennen asetuksen muuttamista, ja asetus kuuluu sovittimelle, ei vieraan ohjelmistolle.

Silta antaa vieraalle oman vuokran ja oman näkyvyytensä

Silta välittää vieraan kehykset fyysiselle segmentille, joten DHCP antaa sille vuokran ja verkko kohtelee sitä erillisenä isäntänä. Jokainen sillattu vieras voi pitää riippumatonta tunnelia omalla oletusreitillään, eikä isännän taulukko muutu koskaan. Hinta on näkyvyys: vieras vastaa lähetyksiin, ilmestyy naapuritaulukoihin ja joutuu kytkimen porttiturvallisuuden ja langattomien asiakkaiden eristyksen alaiseksi. Isännän tunnelikaan ei kata tätä järjestelyä, koska vieraan kehykset eivät koskaan kulje isännän pinon läpi.

Tämä ero NAT-tapaukseen kannattaa sanoa suoraan eikä jättää vihjeeksi. Sillattu vieras tarvitsee oman asiakkaan ja omat tunnuksensa aina, kun sen liikenteen on käytettävä tunnelia. Kun vieraan on pysyttävä näkymättömänä paikalliselle verkolle, NAT tai vain sisäinen verkko hallitulla reitityksellä on parempi ratkaisu.

Miksi vieraasta ei voi tulla isännän yhdyskäytävää

Vieraan tunnelin lainaamiselle isännälle ei ole tuettua kytkintä kummassakaan suuressa hypervisorissa. Isännällä ei ole reittiä vieraan tunneliin eikä käännössääntöä, joka osoittaisi siihen, joten vieraan ja isännän liikenne pysyvät erillisinä virtauksina erillisine omistajineen. Tämä suunta epäonnistuu sovittimen tilasta riippumatta.

Toimivat korvikkeet ovat edelleenohjaukset ja välityspalvelimet. SSH:n paikallinen edelleenohjaus antaa isännän yhdistää omaan loopbackiinsa, kun vieras kantaa virran tunneliin, mikä kattaa TCP-palvelut ilman toisen asiakkaan asentamista. Isännän oman IP-liikenteen saaminen käyttämään vieraan tunnelia sen sijaan vaatii reitittimen vieraan sisään sekä nimenomaisen reitin isännällä ja käännöksen isännällä. Se on pieni verkkosuunnittelu eikä valintaruutu, ja se vaatii suunnitelman paluupolulle. Kun vieras on olemassa vain asiakkaan ajamista varten, laita asiakas isännälle ja poista ylimääräinen hyppy.

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

Selvittimet ja reitit eivät ylitä rajaa

DNS seuraa sovitinta, joka valinnan vastaanotti, joten vieras ei peri isännän tunnelin selvittintä eikä isäntä saa koskaan tietää vieraan työnnettyä palvelinta. Työnnetyt dhcp-option DNS-arvot pätevät rajapinnalle, joka ne hyväksyi, ja siksi sillattu vieras ilman asiakasta ei voi selvittää sisäisiä nimiä. NAT-vieras käyttää yleensä sen sijaan hypervisorin DNS-käsittelyä, ja ero näkyy yhdellä komennolla ympäristöä kohti.

# 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

Lue selvittin ja reitti vieraan sisällä ennen kuin oletat kumman tahansa seuraavan isäntää. Lisää tunnelin selvittin vieraan omaan sovittimeen, kun sisäiset nimet on selvitettävä siellä, ja tarkista sitten nimellä, joka on olemassa vain tunnelin takana. Kirjaa sovittimen tila, tunnelin omistaja ja selvittimen lähde jokaista VM:ää kohti, koska nämä kolme tosiasiaa vastaavat lähes jokaiseen myöhempään kysymykseen. Muut hypervisorit nimeävät tilat uudelleen ja jättävät periaatteen ennalleen.