VirtualBox NAT vai tilts: kur beidzas VM VPN

Divi dažādi jautājumi nāk kopā katru reizi, kad virtuālā mašīna palaiž VPN klientu, un to atbildes atšķiras. Pirmais ir, vai tunelis viesa iekšienē aizsargā saimnieku, un otrais ir, vai tunelis uz saimnieka pārklāj viesi. Adaptera režīms izšķir abus, vairāk nekā pati VPN programmatūra. NAT adapters padara saimnieku par redzamo galapunktu, bet tilta adapters ievieto viesi tīklā ar savu adresi.

Kas īsti pabeidz šifrēto sesiju

Šifrēta sesija pieder mašīnai, kas to pabeidz, un tā ir viesis, kad klients darbojas VM iekšienē. Caur šo tuneli iet tikai trafiks, kas nonāk viesa virtuālajā adapterī, un hipervizors nekad pats nevirza citu mašīnu caur viesi. Tāpēc viesis var uzturēt strādājošu tuneli, kamēr saimnieks pārlūko atklātā tīklā. Pretējais nav simetrisks, un tieši šī asimetrija ir daļa, ko lielākā daļa ceļvežu saprot nepareizi.

Kuru adresi redz ārējais tīkls, ir jautājums, uz kuru atbild adaptera režīms. Kad tas ir izlemts, pārklājums pārstāj būt politikas jautājums un kļūst mehānisks. Viss turpmāk izriet no šiem diviem faktiem.

NAT pārraksta viesi, līdz tas izskatās kā saimnieks

Ar NAT hipervizors pārraksta katru viesa paketi uz saimnieka adresi, pirms tā sasniedz pirmo komutatoru. Pēc tam šis trafiks tiek nodots saimnieka paša tīkla steksam, kur tas seko saimnieka maršrutēšanas tabulai, tostarp noklusējuma maršrutam, kas pieder tunelim uz saimnieka. Tāpēc NAT viesis bez jebkādas konfigurācijas tiek pārklāts ar tuneli uz saimnieka, kas ir pretēji tam, ko liecina virziens no viesa uz saimnieku.

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

Viesis, kas palaiž savu klientu, pabeidz šo tuneli viesa iekšienē, un šifrētais trafiks pēc tam iziet caur to pašu pārrakstīšanu, tāpēc saimnieka lietotnes saglabā savu ceļu un savu izejas adresi. VirtualBox šajā režīmā pārvalda arī nosaukumu izšķiršanu un pārsūta viesa vaicājumus caur savu dzinēju, ja vien --natdnshostresolver1 nav iespējots. Tā iespējošana nodod viesa meklējumus saimnieka atrisinātājam, kas izlabo izšķiršanu, kad saimnieka paša skatījums ir pareizs, un tikpat labi nodod atrisinātāju, kas var pastāvēt tikai tuneļa iekšienē. VM ir jāizslēdz pirms iestatījuma maiņas, un iestatījums pieder adapterim, nevis viesa programmatūrai.

Tilts dod viesim savu nomu un savu atklātību

Tilts pārsūta viesa kadrus uz fizisko segmentu, tāpēc DHCP dod tam nomu un tīkls to uzskata par atsevišķu saimnieku. Katrs tiltā iekļautais viesis var uzturēt neatkarīgu tuneli ar savu noklusējuma maršrutu, un saimnieka tabula nekad nemainās. Cena ir atklātība: viesis atbild uz apraides pakešu sūtījumiem, parādās kaimiņu tabulās un nonāk zem komutatora portu drošības un bezvadu klientu izolācijas. Tunelis uz saimnieka arī nepārklāj šo izkārtojumu, jo viesa kadri nekad neiet caur saimnieka steksu.

Šo atšķirību no NAT gadījuma ir vērts pateikt tieši, nevis atstāt kā norādi. Tiltā iekļautam viesim vajadzīgs savs klients un savi pieteikšanās dati ikreiz, kad tā trafikam jāizmanto tunelis. Tur, kur viesim jāpaliek neredzamam vietējam tīklam, NAT vai tikai iekšējs tīkls ar kontrolētu maršrutēšanu ir labāks risinājums.

Kāpēc viesis nevar būt saimnieka vārteja

Viesa tuneļa aizdošanai saimniekam nav atbalstīta slēdža nevienā no diviem lielajiem hipervizoriem. Saimniekam nav maršruta viesa tunelī un nav tulkošanas noteikuma, kas uz to norādītu, tāpēc viesa un saimnieka trafiks paliek atsevišķas plūsmas ar atsevišķiem īpašniekiem. Šis virziens neizdodas neatkarīgi no adaptera režīma.

Derīgie aizstājēji ir pāradresācijas un starpnieki. Vietējā SSH pāradresācija ļauj saimniekam pievienoties savai atgriezeniskajai cilpai, kamēr viesis nes straumi tunelī, un tas pārklāj TCP pakalpojumus, neinstalējot otru klientu. Likt saimnieka pašam IP trafikam tā vietā izmantot viesa tuneli prasa maršrutētāju viesa iekšienē, kā arī skaidru maršrutu uz saimnieka un tulkošanu uz saimnieka. Tas ir mazs tīkla projekts, nevis izvēles rūtiņa, un tam vajadzīgs atgriešanās ceļa plāns. Kad viesis pastāv tikai klienta palaišanai, liec klientu uz saimnieka un dzēs lieko lēcienu.

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

Atrisinātāji un maršruti nešķērso robežu

DNS seko adapterim, kas saņēma opciju, tāpēc viesis nemanto saimnieka tuneļa atrisinātāju un saimnieks nekad neuzzina viesim iespiesto serveri. Iespiestās dhcp-option DNS vērtības attiecas uz saskarni, kas tās pieņēma, un tāpēc tiltā iekļauts viesis bez klienta nevar atrisināt iekšējos nosaukumus. NAT viesis parasti izmanto hipervizora DNS apstrādi, un atšķirība redzama vienā komandā katrā vidē.

# 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

Izlasiet atrisinātāju un maršrutu viesa iekšienē, pirms pieņemat, ka kāds no tiem seko saimniekam. Pievienojiet tuneļa atrisinātāju viesa paša adapterim, kad iekšējie nosaukumi tur jāizšķir, un pēc tam pārbaudiet ar nosaukumu, kas pastāv tikai aiz tuneļa. Pierakstiet katrai VM adaptera režīmu, tuneļa īpašnieku un atrisinātāja avotu, jo šie trīs fakti atbild uz gandrīz katru vēlāko jautājumu. Citi hipervizori pārdēvē režīmus un atstāj principu neskartu.