Gumagana ang browser sa loob ng virtual machine, at hindi makapagdala ng data ang VPN client sa parehong guest. Malinaw na may konektividad ang guest, kaya nasa kung ano ang kailangan ng panlabas na protocol ng VPN at kung ano ang ipapasa ng virtual NAT ang problema. Tatlong kondisyon ang nagtatakda ng resulta: aling proseso ang may VPN, ano ang hitsura ng panlabas na palitan sa wire, at kung ang mode ng adapter ay ang iniisip mo. Ang pagpangalan sa kondisyong mababago mo ang buong desisyon.

Hanapin ang proseso ng VPN bago sisihin ang network

Magpasya muna kung tumatakbo ang VPN sa loob ng guest o sa host, dahil magkaiba ang pagkabigo ng dalawang kaayusan. Ang client sa loob ng guest ay gumagawa ng sarili nitong panlabas na koneksyon sa pamamagitan ng adapter ng guest at anumang pagsasalin sa likod nito. Ang host VPN ay humuhuli sa trapiko ng guest ayon sa patakaran ng host at hypervisor, na isang hiwalay na punto ng paghuli na may sariling mga patakaran. Maaari silang tumakbo nang sabay at guluhin ang ebidensya, kaya tukuyin kung alin ang dapat magdala ng trapikong ito bago hawakan ang alinman.

Isulat ngayon ang mode ng adapter ng guest, bago baguhin ang anuman. Ang nag-iisang halagang iyon ang nagpapaliwanag sa karamihan ng sumusunod, at ito ang unang itatanong ng kahit sino mamaya.

Ang panlabas na palitan ang nagtatakda ng pagiging tugma

Ang gabay sa network ng VirtualBox ay naglilista ng mga limitasyon ng NAT na mahalaga dito: hindi ito magpapasa ng ibang protocol maliban sa TCP at UDP, ang GRE ay binanggit na hindi suportado, at ang PPTP ay ibinigay bilang apektadong halimbawa. Gumagamit ang PPTP ng TCP control exchange at GRE para sa data, kaya maaaring magtagumpay ang control connection habang hindi makatawid ang data path sa parehong hangganan. Dalawang magkaibang ebidensya ito, at isa lang ang tungkol sa pagdadala ng trapiko. Ang pagpapahintulot sa TCP port 47 sa isang firewall rule ay hindi kapareho ng pagpapahintulot sa IP protocol 47, at ang dalawa ay laging pinaghihiwalay.

Panatilihing nakatali ang limitasyon sa kaayusang NAT na ito at hindi sa bawat device na gumagamit ng salitang NAT. Ang pisikal na router ay maaaring magpasa ng GRE nang walang reklamo habang itinatapon ito ng virtual NAT, at ang ibang hypervisor ay gumagawa ng sariling pagpili sa ipapasa nito. Saan man nag-aalok ang organisasyon ng aprubadong transport sa loob ng TCP o UDP, gamitin ang suportadong client at profile nito para sa landas na iyon. Ang pagiging tugma ay isang kinakailangan sa ilan, at hindi nito itinatag ang pagtitiwala sa server o pahintulot ng account o gumaganang pribadong ruta.

Ano ang tunay na binabago ng tulay

Ang tulay ay nagbibigay ng MAC address ng guest sa pisikal na segment sa halip na itago ito sa likod ng pagsasalin. Pagkatapos ay kumukuha ang guest ng address mula sa anumang DHCP server na naglilingkod sa segment na iyon, sumasagot ng ARP para sa address na iyon, at lumilitaw sa upstream switch bilang isa pang port. Inaalis nito ang virtual translation path, na siyang eksaktong dahilan kung bakit inirerekomenda ito ng lumang recipe, at binabago nito ang tatlong iba pang bagay sa parehong sandali. Ang pag-address ay nagmumula na ngayon sa lokal na segment at hindi sa hypervisor, ang pagkalantad ay nangangahulugang nakikita ng segment na iyon ang guest, at ang pagtanggap ay nakasalalay sa port ng switch at sa patakaran nito. Ang bawat isa sa mga ito ay maaaring maging dahilan upang tanggihan ang pagbabago, at wala sa mga ito ang tungkol sa protocol ng VPN.

Ang pag-bridge ay hindi nag-i-install ng nawawalang plugin, hindi nagbibigay ng hindi available na secret agent, at hindi nag-aayos ng pagtanggi sa authentication. Hindi rin nito ginagawang magandang pagpipilian ang isang lumang protocol, at kung saan may maintained na kapalit ang operator, iyon ang desisyon at hindi ang pagpapalit ng hypervisor. Ang port forwarding ay isang ganap na ikatlong papel: naglalathala ito ng papasok na serbisyo at walang ginagawa para sa panlabas na protocol ng palabas na client.

Dalawang tunnel, dalawang bakas ng ebidensya

Kailangan ng guest VPN ng magagamit na landas mula sa interface ng guest hanggang sa kapares nito bago maging mahalaga ang anumang panloob na address o pribadong ruta. Kung saan may host VPN, maaari nitong ipasa o harangan ang panlabas na palitan ayon sa sariling patakaran, at ang panloob na tunnel ng guest ay nagsisimula lamang pagkatapos ng tagumpay ng panlabas. Ang saklaw ng walang layer ay hindi mababasa mula sa isang konektadong icon o sa pampublikong address ng browser ng host.

Itago ang unang mensahe ng error at hindi ang huli, dahil pinapangalanan ng pinakaunang pagkabigo ang layer. Palitan ang isang suportadong kaayusan ng network sa isang pagkakataon, gamit ang parehong profile ng guest at parehong mga kredensyal, upang may kahulugan ang paghahambing. Magpasya mula sa pagkabigo kung aling yugto ang nasira: lokal na integrasyon, transport, authentication, o pag-access sa resources pagkatapos ng tunnel. Bawat isa ay may ibang may-ari, at isa lang ang tanong tungkol sa hypervisor.

Aling kondisyon ang tunay na humaharang sa iyo

Ngayon ang desisyon ay kumikitid sa tatlong tanong na may magkaibang sagot. Kung ang panlabas na protocol ay nasa labas ng TCP at UDP, ang NAT mode ang hadlang, at ang daan pasulong ay tulay o aprubadong TCP/UDP transport. Kung natapos ang panlabas na palitan at hindi ang data path, ang hadlang ay pareho sa nakita sa ikalawang ebidensya. Kung umangat ang tunnel at hindi tumutugon ang resources, nalampasan na ng problema ang hypervisor patungo sa routing o patakaran.

Isulat ang sagot kasama ang mode ng adapter sa tabi, kung hindi ay uulitin ng susunod na tao ang parehong hapon. Subukan ang aktwal na aplikasyon at paglutas ng pangalan sa loob ng guest pagkatapos ng anumang pagwawasto, pagkatapos ay kumonekta muli at subukan ang patakaran ng pagkabigo. Ang gumaganang web page sa pamamagitan ng tunnel ay nagpapatunay lamang na gumagana ang web path, na isang mas maliit na pag-aangkin kaysa sa pakiramdam sa sandaling iyon.

Kaugnay na mga artikulo