Zergatik huts egiten du zure gonbidatu VPNak VirtualBox NATaren atzean?

Makinaren barruko nabigatzaile batek funtzionatzen du, eta gonbidatu bereko VPN bezeroak ezin ditu datuak eraman. Gonbidatuak konektibitatea duela argi dago, beraz hutsa VPNaren kanpoko protokoloak behar duenean eta NAT birtualak pasatuko duenean dago. Hiru baldintzek erabakitzen dute emaitza: zein prozesuk duen VPNa, nola dagoen kanpoko trukea kablean eta adaptagailuaren modua uste duzuna den. Alda dezakezun baldintza izendatzea da erabaki osoa.

Kokatu VPN prozesua, sarea erruduntzat jo aurretik

Erabaki lehenago VPNa gonbidatuaren barruan edo ostalarian exekutatzen den, bi antolamenduek modu ezberdinean huts egiten baitute. Gonbidatuaren barruko bezero batek bere kanpoko konexioa eraikitzen du gonbidatuaren adaptagailuaren eta haren atzean dagoen edozein itzulpenen bidez. Ostalariaren VPNak gonbidatuaren trafikoa harrapatzen du ostalariaren eta hiperbisorearen politikaren arabera, arau propioak dituen harrapatze-puntu bereizia baita. Biak aldi berean ibil daitezke eta frogak nahas ditzakete, beraz identifikatu trafiko hau eraman behar duena edozeini ukitu aurretik.

Idatzi gonbidatuaren adaptagailuaren modua orain, ezer aldatu aurretik. Balio bakar horrek azaltzen du ondoren datozen gehienak, eta geroago inork galdetuko dizun lehen gauza da.

Kanpoko trukeak erabakitzen du bateragarritasuna

VirtualBoxen sare-gidak hemen garrantzitsuak diren NAT murrizketak zerrendatzen ditu: ez ditu TCP eta UDP ez diren protokoloak pasatuko, GRE onartu gabe gisa aipatzen da, eta PPTP eragindako adibide gisa ematen da. PPTPk TCP kontrol-trukea eta GRE erabiltzen ditu datuetarako, beraz kontrol-konexioak arrakasta izan dezake datu-bideak muga bera zeharkatu ezin duen bitartean. Bi frogak desberdinak dira, eta horietako bat bakarrik da trafikoa eramateari buruzkoa. TCP 47 portua suebaki-arau batean baimenduz ez da gauza bera IP 47 protokoloa baimenduz, eta biak etengabe nahasten dira.

Mantendu murrizketa NAT antolamendu honi lotuta, NAT hitza erabiltzen duen gailu bakoitzari lotu gabe. Router fisiko batek GRE arazorik gabe pasa dezake NAT birtualak baztertzen duen bitartean, eta beste hiperbisore batek bere erabakia hartzen du zer birbidaltzen duen. Erakundeak TCP edo UDP barruan onartutako garraio bat eskaintzen duenean, erabili haren bezero eta profil onartuak bide horretarako. Bateragarritasuna hainbat baldintzaren arteko bat da, eta ez du ez zerbitzariaren konfiantza ez kontuaren baimena ezta funtzionatzen duten bide pribatuak ezartzen.

Zer aldatzen du benetan zubiak

Zubi batek gonbidatuaren MAC helbidea segmentu fisikora ematen du, itzulpenaren atzean ezkutatu beharrean. Gonbidatuak segmentu horri zerbitzatzen dion DHCP zerbitzarietatik helbidea hartzen du, helbide horretarako ARP erantzuten du, eta gorako kommutagailuarentzat beste portu bat balitz bezala agertzen da. Horrek itzulpide birtuala kentzen du, eta horixe da errezeta zahar batek gomendatzen duen arrazoia, eta aldi berean beste hiru gauza aldatzen ditu. Helbideratzea orain tokiko segmentutik dator, ez hiperbisoretik, esposizioak gonbidatua segmentu horretarako ikusgai dagoela esan nahi du, eta onarpena kommutagailuaren portuaren eta haren politikaren araberakoa da. Horietako bakoitza aldaketa baztertzeko arrazoi izan daiteke, eta bat ere ez da VPN protokoloari buruzkoa.

Zubiak ez du falta den pluginik instalatzen, ez du eskuragarri ez dagoen agente sekreturik ematen eta ez du autentifikazio ukapenik konpontzen. Ez du protokolo zaharkitu bat aukera ona bihurtzen ere, eta operadoreak mantendutako ordezko bat duenean, hura da erabakia, ez hiperbisorea aldatzea. Portu-birbidalketa erabat hirugarren rol bat da: sarrerako zerbitzu bat argitaratzen du eta irteerako bezero baten kanpoko protokoloarentzat ezer ez du egiten.

Bi tunel, bi froga-arrasto

Gonbidatu VPNak bide erabilgarri bat behar du gonbidatuaren interfazetik bere parekidera, barruko helbide edo bide pribatu bat garrantzitsua izan aurretik. Ostalari VPN bat badago, kanpoko truke hori birbidal edo blokea dezake bere politikaren arabera, eta gonbidatuaren barruko tunela kanpokoak arrakasta izan ondoren baino ez da hasten. Ez da geruzaren estaldura ikono konektatu batetik edo ostalariaren nabigatzailearen helbide publikotik irakur daitekeenik.

Atxiki lehen errore-mezua eta ez azkena, hasierako hutsak geruza izendatzen baitu. Aldatu onartutako sare-antolamendu bat aldi berean, gonbidatu-profil berarekin eta kredentzial berberekin, konparazioak zentzua izan dezan. Hutsaren arabera erabaki zein etapak huts egin duen: tokiko integrazioa, garraioa, autentifikazioa edo tunela altxatu ondorengo baliabide-sarbidea. Horietako bakoitzak jabe desberdin bat du, eta bakarra da hiperbisore-kontua.

Zein baldintzak blokeatzen zaitu benetan

Orain erabakia erantzun desberdinak dituzten hiru galderetara murrizten da. Kanpoko protokoloa TCP eta UDPtik kanpo badago, NAT modua da murrizketa, eta aurrera egiteko bidea zubia edo onartutako TCP/UDP garraioa da. Kanpoko trukea osatzen bada eta datu-bidea ez, murrizketa bigarren frogan ikusten den bera da. Tunela altxatzen bada eta baliabideek ez badute erantzuten, arazoa hiperbisoretik harago joan da jada bideratze edo politikara.

Idatzi erantzuna adaptagailuaren moduarekin batera, bestela hurrengo pertsonak arratsalde bera errepikatuko du. Egiaztatu gonbidatuaren barruan benetako aplikazioa eta izenen ebazpena edozein zuzenketaren ondoren, gero berriz konektatu eta probatu huts-politika. Tunelaren bidez funtzionatzen duen web orrialde batek web-bideak funtzionatzen duela baino ez du frogatzen, une horretan sentitzen dena baino baieztapen txikiagoa.