Pse dështon VPN i mysafirit pas NAT-it të VirtualBox?

Një shfletues brenda makinës virtuale punon, dhe klienti VPN në të njëjtin mysafir nuk mund të transportojë të dhëna. Mysafiri ka qartë lidhje, kështu që defekti qëndron në atë që kërkon protokolli i jashtëm i VPN-së dhe në atë që NAT-i virtual do të lërë të kalojë. Rezultatin e vendosin tre kushte: cili proces zotëron VPN-në, si duket shkëmbimi i jashtëm në tel dhe a është modaliteti i përshtatësit ai që mendoni. Të emërtosh kushtin që mund të ndryshosh është e gjithë vendimi.

Gjeni procesin e VPN-së përpara se të fajësoni rrjetin

Vendosni fillimisht nëse VPN-ja punon brenda mysafirit apo në host, sepse të dyja rregullimet dështojnë ndryshe. Një klient brenda mysafirit ndërton lidhjen e vet të jashtme përmes përshtatësit të mysafirit dhe çdo përkthimi pas tij. Një VPN hosti kap trafikun e mysafirit sipas politikës së hostit dhe hipervizorit, që është një pikë kapjeje e veçantë me rregullat e veta. Ato mund të punojnë njëkohësisht dhe të turbullojnë provat, prandaj identifikoni se cila duhet ta mbajë këtë trafik përpara se të prekni ndonjërën.

Shkruani tani modalitetin e përshtatësit të mysafirit, përpara se të ndryshoni ndonjë gjë. Ai vlerë i vetëm shpjegon pjesën më të madhe të asaj që vjen, dhe është gjëja e parë që dikush do t'ju pyesë më vonë.

Shkëmbimi i jashtëm vendos përputhshmërinë

Udhëzuesi i rrjetit të VirtualBox rendit kufizimet e NAT-it që kanë rëndësi këtu: nuk lë të kalojnë protokolle përveç TCP dhe UDP, GRE përmendet si i pambështetur, dhe PPTP jepet si shembull i prekur. PPTP përdor një shkëmbim kontrolli TCP dhe GRE për të dhënat, kështu që lidhja e kontrollit mund të ketë sukses ndërkohë që rruga e të dhënave nuk mund të kalojë të njëjtin kufi. Këto janë dy prova të ndryshme, dhe vetëm njëra prej tyre ka të bëjë me mbajtjen e trafikut. Lejimi i portit TCP 47 në një rregull muri zjarri nuk është i njëjtë me lejimin e protokollit IP 47, dhe të dy ngatërrohen vazhdimisht.

Mbajeni kufizimin të lidhur me këtë rregullim NAT dhe jo me çdo pajisje që përdor fjalën NAT. Një ruter fizik mund ta lërë GRE të kalojë pa ankesë ndërkohë që NAT-i virtual e hedh poshtë, dhe një hipervizor tjetër bën zgjedhjen e vet për atë që përcjell. Aty ku organizata ofron një transport të miratuar brenda TCP ose UDP, përdorni klientin dhe profilin e mbështetur të tij për atë rrugë. Përputhshmëria është një kërkesë ndër disa, dhe nuk vendos as besimin te serveri, as lejen e llogarisë, as rrugë private që punojnë.

Çfarë ndryshon vërtet ura

Një urë ia dorëzon adresën MAC të mysafirit segmentit fizik në vend që ta fshehë pas përkthimit. Mysafiri merr pastaj një adresë nga çdo server DHCP që i shërben atij segmenti, përgjigjet me ARP për atë adresë, dhe shfaqet përpara komutatorit të sipërm si një port më shumë. Kjo heq rrugën e përkthimit virtual, që është pikërisht arsyeja pse një recetë e vjetër e rekomandon, dhe ndryshon tre gjëra të tjera në të njëjtin moment. Adresimi tani vjen nga segmenti lokal dhe jo nga hipervizori, ekspozimi do të thotë që mysafiri është i dukshëm për atë segment, dhe pranimi varet nga porti i komutatorit dhe politika e tij. Secila prej tyre mund të jetë arsye për të refuzuar ndryshimin, dhe asnjëra nuk ka të bëjë me protokollin VPN.

Ura nuk instalon një shtojcë që mungon, nuk furnizon një agjent sekret të padisponueshëm dhe nuk riparon një refuzim vërtetimi. As nuk e bën një protokoll të vjetruar zgjedhje të mirë, dhe aty ku operatori ka një zëvendësues të mirëmbajtur, vendimi është ai dhe jo ndryshimi i hipervizorit. Përcjellja e portit është një rol krejt i tretë: publikon një shërbim hyrës dhe nuk bën asgjë për protokollin e jashtëm të një klienti dalës.

Dy tunele, dy gjurmë provash

Një VPN mysafiri ka nevojë për një rrugë të përdorshme nga ndërfaqja e mysafirit te homologu i tij përpara se ndonjë adresë e brendshme ose rrugë private të ketë rëndësi. Aty ku ka një VPN hosti, ajo mund ta përcjellë ose bllokojë atë shkëmbim të jashtëm sipas politikës së vet, dhe tuneli i brendshëm i mysafirit fillon vetëm pasi ai i jashtëm të ketë sukses. Mbulimi i asnjë shtrese nuk lexohet nga një ikonë e lidhur ose nga adresa publike e shfletuesit të hostit.

Mbani mesazhin e parë të gabimit dhe jo të fundit, sepse dështimi më i hershëm emërton shtresën. Ndryshoni një rregullim rrjeti të mbështetur në një kohë, me të njëjtin profil mysafiri dhe të njëjtat kredenciale, që krahasimi të thotë diçka. Vendosni nga dështimi cila fazë u thye: integrimi lokal, transporti, vërtetimi ose aksesi në burime pasi tuneli është ngritur. Secili prej tyre ka një pronar tjetër, dhe vetëm njëri është pyetje hipervizori.

Cila kusht ju bllokon në të vërtetë

Tani vendimi ngushtohet në tre pyetje me përgjigje të ndryshme. Nëse protokolli i jashtëm qëndron jashtë TCP dhe UDP, modaliteti NAT është kufizimi, dhe rruga përpara është ura ose një transport TCP/UDP i miratuar. Nëse shkëmbimi i jashtëm përfundon dhe rruga e të dhënave jo, kufizimi është i njëjti që shihet në provën e dytë. Nëse tuneli ngrihet dhe burimet nuk përgjigjen, problemi e ka kaluar tashmë hipervizorin drejt rrugëzimit ose politikës.

Shkruani përgjigjen me modalitetin e përshtatësit pranë, përndryshe personi tjetër do të përsëritë të njëjtën pasdite. Pas çdo korrigjimi provoni aplikacionin real dhe zgjidhjen e emrave brenda mysafirit, pastaj rilidheni dhe provoni politikën e dështimit. Një faqe web që punon përmes tunelit provon vetëm se rruga web punon, që është një pretendim më i vogël sesa duket në atë moment.