Zakaj vaš gostujoči VPN ne deluje za NAT VirtualBoxa?

Brskalnik v virtualnem stroju deluje, odjemalec VPN na istem gostu pa ne more prenašati podatkov. Gost očitno ima povezljivost, zato je napaka v tem, kar zahteva zunanji protokol VPN in kar bo virtualni NAT spustil skozi. Izid določajo trije pogoji: kateri proces ima VPN, kako je videti zunanja izmenjava na žici in ali je način adapterja tisti, ki ga mislite. Poimenovati pogoj, ki ga lahko spremenite, je cela odločitev.

Poiščite proces VPN, preden krivite omrežje

Najprej se odločite, ali VPN teče znotraj gosta ali na gostitelju, ker se oba ustroja okvarita različno. Odjemalec znotraj gosta zgradi svojo zunanjo povezavo prek adapterja gosta in kakršnega koli prevoda za njim. Gostiteljski VPN prestreže promet gosta skladno s politiko gostitelja in hipervizorja, kar je ločena točka prestrezanja z lastnimi pravili. Lahko tečeta hkrati in zameglita dokaze, zato ugotovite, kateri naj bi nosil ta promet, preden se dotaknete katerega koli.

Zapišite način adapterja gosta zdaj, preden karkoli spremenite. Ta ena vrednost pojasni večino tega, kar sledi, in je prva stvar, ki vas bo kdo pozneje vprašal.

Zunanja izmenjava odloča o združljivosti

Vodnik po omrežjih VirtualBox navaja omejitve NAT, ki so tu pomembne: ne spusti skozi drugih protokolov razen TCP in UDP, GRE je naveden kot nepodprt, PPTP pa je podan kot prizadet primer. PPTP uporablja krmilno izmenjavo TCP in GRE za podatke, zato lahko krmilna povezava uspe, medtem ko podatkovna pot ne more prestopiti iste meje. To sta dva različna dokaza in samo eden od njiju govori o prenašanju prometa. Dovoliti vrata TCP 47 v pravilu požarnega zidu ni isto kot dovoliti protokol IP 47, in ta dva se nenehno zamenjujeta.

Omejitev držite vezano na to ureditev NAT, ne pa na vsako napravo, ki uporablja besedo NAT. Fizični usmerjevalnik lahko spusti GRE brez pritožbe, medtem ko ga virtualni NAT zavrže, drug hipervizor pa se sam odloči, kaj posreduje. Kjer organizacija ponuja odobren prenos znotraj TCP ali UDP, uporabite njenega podprtega odjemalca in profil za to pot. Združljivost je ena od več zahtev in ne vzpostavlja ne zaupanja v strežnik ne dovoljenja računa ne delujočih zasebnih poti.

Kaj premostitev zares spremeni

Most preda MAC naslov gosta fizičnemu segmentu, namesto da bi ga skril za prevodom. Gost nato prevzame naslov od katerega koli strežnika DHCP, ki oskrbuje ta segment, odgovori na ARP za ta naslov in se pred nadrejenim stikalom prikaže kot še ena vrata. To odstrani pot virtualnega prevoda, kar je prav razlog, da jo stari recept priporoča, in hkrati spremeni še tri stvari. Naslavljanje zdaj prihaja iz lokalnega segmenta in ne iz hipervizorja, izpostavljenost pomeni, da je gost viden temu segmentu, sprejem pa je odvisen od vrat stikala in njegove politike. Vsaka od tega je lahko razlog za zavrnitev spremembe in nobena ni o protokolu VPN.

Premoščanje ne namesti manjkajočega vtičnika, ne zagotovi nedosegljivega tajnega agenta in ne popravi zavrnitve overjanja. Prav tako ne naredi zastarelega protokola dobre izbire, in kjer ima operater vzdrževano zamenjavo, je odločitev ta in ne menjava hipervizorja. Posredovanje vrat je povsem tretja vloga: objavi dohodno storitev in ne naredi ničesar za zunanji protokol odhodnega odjemalca.

Dva tunela, dve sledi dokazov

Gostujoči VPN potrebuje uporabno pot od vmesnika gosta do svojega partnerja, preden postane pomemben kateri koli notranji naslov ali zasebna pot. Kjer je prisoten gostiteljski VPN, lahko to zunanjo izmenjavo posreduje ali blokira po svoji politiki, notranji tunel gosta pa se začne šele po uspehu zunanjega. Pokritosti nobenega sloja ni mogoče razbrati z ene same povezane ikone ali z javnega naslova brskalnika na gostitelju.

Obdržite prvo sporočilo o napaki in ne zadnjega, ker najzgodnejša okvara poimenuje sloj. Spreminjajte eno podprto omrežno ureditev naenkrat, z istim profilom gosta in istimi poverilnicami, da bo primerjava kaj pomenila. Po okvari ugotovite, katera stopnja se je zlomila: lokalna integracija, prenos, overjanje ali dostop do virov po dvigu tunela. Vsaka od njih ima drugega lastnika in samo ena je vprašanje hipervizorja.

Kateri pogoj vas dejansko blokira

Zdaj se odločitev zoži na tri vprašanja z različnimi odgovori. Če je zunanji protokol zunaj TCP in UDP, je omejitev način NAT, pot naprej pa je most ali odobren prenos TCP/UDP. Če se zunanja izmenjava zaključi, podatkovna pot pa ne, je omejitev ista kot pri drugem dokazu. Če se tunel dvigne, viri pa ne odgovarjajo, je problem že prešel hipervizor v usmerjanje ali politiko.

Zapišite odgovor z načinom adapterja ob njem, sicer bo naslednja oseba ponovila isto popoldne. Po vsakem popravku preizkusite dejansko aplikacijo in razreševanje imen znotraj gosta, nato se znova povežite in preizkusite politiko okvare. Delujoča spletna stran skozi tunel dokazuje le, da spletna pot deluje, kar je manjša trditev, kot se zdi v tistem trenutku.