Zinxhirimi i dy VPN-ve: çfarë fsheh dhe sa kushton

Dy tunele të mbivendosur nuk ju bëjnë anonim. Ata i ndajnë vëzhgimet mes dy ofruesve, kështu që asnjëri nuk e sheh adresën tuaj të shtëpisë dhe destinacionin tuaj njëkohësisht. Ky është një përfitim i vërtetë, por i ngushtë, dhe vjen me probleme rrugëtimi, DNS dhe MTU që shfaqen herën e parë që mbështeteni tek ai.

1. Vendos për çfarë shërben hopi i dytë

Shkruaje qëllimin në një fjali përpara se të konfigurosh çdo gjë. Nëse bëhet fjalë që ofruesi yt i internetit të mos shohë cilat sajte viziton, mjafton një tunel. Nëse bëhet fjalë që asnjë ofrues i vetëm të mos mund ta lidhë adresën tënde me trafikun tënd, duhen dy. Nëse bëhet fjalë që askush të mos të identifikojë, asnjë numër hopesh nuk arrin atje.

Zinxhiri është vetëm aq i fortë sa regjistrimi i ofruesit më të dobët dhe të dhënat e llogarisë që të dy mbajnë. Pagesat, email-i i regjistrimit dhe telemetria e aplikacionit qëndrojnë plotësisht jashtë tunelit.

2. Bëje pikën fundore të brendshme të arritshme përmes tunelit të jashtëm

Dështimi i zakonshëm është që tuneli i brendshëm nuk vendoset kurrë. Një lidhje e jashtme në modalitetin tunel të plotë zotëron rrugën e parazgjedhur, kështu që përpjekja e klientit të brendshëm për të arritur pikën e vet fundore gëlltitet nga tuneli i jashtëm dhe hidhet ose futet në lak. Pika fundore e brendshme ka nevojë për një rrugë të qartë përmes ndërfaqes së jashtme, të instaluar përpara se klienti i brendshëm të nisë. Përndryshe shtrëngimi i duarve garon me rrugën dhe humbet.

WireGuard tregon të njëjtin konflikt nga ana tjetër. Tek çdo peer, AllowedIPs vendos cilat destinacione hyjnë në atë tunel, kështu që një ndërfaqe e brendshme që kërkon çdo adresë kërkon edhe pikën fundore të jashtme, përveç nëse fiton një rrugë më specifike. AllowedIPs të mbivendosura në dy ndërfaqe është një konfigurim në të cilin njëra anë humbet në heshtje.

Zinxhirimi me kontejnerë e bën ndarjen të qartë dhe kurthin të dukshëm. Një kontejner me hapësirën e vet të emrave, rrugën e vet të parazgjedhur dhe një klient brenda tij përcjell atë që priti i dërgon; priti nuk fillon ta përdorë vetë atë rrugë. Aktivizo përcjelljen, shto një rrugë për tunelin e kontejnerit dhe drejto shërbimin te adresa e kontejnerit.

3. Mbaje DNS në të njëjtën rrugë

DNS duhet të udhëtojë atje ku udhëton trafiku. Nëse ofruesi i brendshëm shtyn zgjidhës dhe priti ende pyet ata lokalë, ato kërkime zbulojnë pikërisht sajtet që tuneli duhej të fshihte. Kontrollo me një kapje në çdo ndërfaqe tuneli në vend që t'i besosh panelit të statusit të klientit. Një rrjedhje këtu është e padukshme gjatë shfletimit normal dhe e dukshme në një kapje.

Modelet me DNS të ndarë e bëjnë këtë më të vështirë, sepse një kërkesë për një emër lokal mund t'i përkasë me të drejtë jashtë tunelit. Shkruaje listën e përjashtimeve me qëllim, në vend që ta zbulosh nga zgjidhësi që rastësisht u përgjigj.

4. Vendos MTU-në përpara se përdoruesit ta zbulojnë në vendin tënd

MTU është viktima tjetër e parashikueshme. Dy inkapsulime zbresin dy koka, dhe një tunel i jashtëm që e ka ulur tashmë MTU-në e rrugës lë më pak hapësirë brenda. Simptomat janë të njohura: kërkesat e vogla kalojnë, transferimet e mëdha dhe shtrëngimet TLS ngecin.

ip link set dev wg1 mtu 1280 është zgjidhja e trashë, dhe shtrëngimi i MSS në përcjellës është më i pastër. Riprovimi i lidhjes nuk është fare zgjidhje.

5. Testo dështimin që do të kesh vërtet

Thyeje qëllimisht tunelin e jashtëm dhe shiko çfarë ndodh. Një zinxhir që bie në heshtje në një rrugë të drejtpërdrejtë kur hopi i jashtëm vdes është më i keq se asnjë zinxhir, sepse rrjedh pikërisht në momentin kur besoje se ishe i mbuluar. Një kill switch që ndalon të gjithë trafikun është sjellja për të cilën duhet synuar. Regjistro rezultatin, sepse nuk do të duash ta rizbulosh në mes të një incidenti.

Vonesa dhe një pikë e dytë dështimi janë kostot e përhershme. Dy hope nënkuptojnë edhe dy radhë suporti kur diçka prishet në një orë të papërshtatshme.