Divu VPN ķēdēšana: ko tas slēpj un cik tas maksā

Divi iekļautie tuneļi nepadara jūs anonīmus. Tie sadala novērojumus starp diviem pakalpojumu sniedzējiem, tāpēc neviens no tiem neredz kopā jūsu mājas adresi un galamērķi. Tas ir reāls, bet šaurs ieguvums, un tas nāk ar maršrutēšanas, DNS un MTU problēmām, kas parādās pirmajā reizē, kad uz to paļaujaties.

1. Izlemiet, kam vajadzīgs otrais lēciens

Uzrakstiet mērķi vienā teikumā, pirms kaut ko konfigurējat. Ja mērķis ir, lai jūsu ISP neredzētu, kuras vietnes apmeklējat, to sasniedz viens tunelis. Ja mērķis ir, lai neviens atsevišķs sniedzējs nevarētu saistīt jūsu adresi ar jūsu datplūsmu, to dara divi. Ja mērķis ir, lai neviens nevarētu jūs identificēt, tur neaizved neviens lēcienu skaits.

Ķēde ir tikpat stipra, cik stipri ir vājākā sniedzēja žurnāli un abu uzturētie kontu ieraksti. Maksājumi, reģistrācijas e-pasts un lietotnes telemetrija atrodas pilnīgi ārpus tuneļa.

2. Padariet iekšējo galu sasniedzamu caur ārējo tuneli

Parastā neveiksme ir tā, ka iekšējais tunelis nekad neizveidojas. Ārējais pilna tuneļa savienojums pārvalda noklusējuma maršrutu, tāpēc iekšējā klienta mēģinājumu sasniegt savu galu ārējais tunelis aprīj un atmet vai ievieto cilpā. Iekšējam galam vajadzīgs skaidrs maršruts caur ārējo saskarni, kas uzstādīts pirms iekšējā klienta palaišanas. Citādi rokasspiediens sacenšas ar maršrutu un zaudē.

WireGuard rāda to pašu konfliktu no otras puses. Katra peer AllowedIPs nosaka, kuri galamērķi nonāk šajā tunelī, tāpēc iekšēja saskarne, kas pieprasa visas adreses, pieprasa arī ārējo galu, ja vien neuzvar konkrētāks maršruts. Pārklājas AllowedIPs divās saskarnēs ir konfigurācija, kurā viena puse klusi zaudē.

Konteineru ķēdēšana padara atdalīšanu skaidru un slazdu acīmredzamu. Konteiners ar savu nosaukumvietu, savu noklusējuma maršrutu un klientu iekšpusē pārsūta to, ko tam sūta saimnieks; saimnieks pats nesāk izmantot šo ceļu. Ieslēdziet pārsūtīšanu, pievienojiet maršrutu konteinera tunelim un vērsiet pakalpojumu uz konteinera adresi.

3. Turiet DNS tajā pašā ceļā

DNS jāceļo tur, kur ceļo datplūsma. Ja iekšējais sniedzējs piedāvā resolverus un saimnieks joprojām prasa vietējos, šie vaicājumi atklāj tieši tās vietnes, kuras tunelim bija jāslēpj. Pārbaudiet ar uztveršanu katrā tuneļa saskarnē, nevis uzticieties klienta statusa panelim. Noplūde šeit nav redzama parastā pārlūkošanā un ir acīmredzama uztveršanā.

Sadalītā DNS dizaini to padara grūtāku, jo vaicājums par vietējo nosaukumu var likumīgi piederēt ārpus tuneļa. Izņēmumu sarakstu uzrakstiet apzināti, nevis atklājiet to pēc tā, kurš resolvers nejauši atbildēja.

4. Iestatiet MTU, pirms lietotāji to uzzina jūsu vietā

MTU ir otrs paredzamais upuris. Divi iekapsulējumi atņem divas galvenes, un ārējais tunelis, kas jau ir pazeminājis ceļa MTU, atstāj mazāk vietas iekšpusē. Simptomi ir pazīstami: mazi pieprasījumi iziet, lieli pārsūtījumi un TLS rokasspiedieni iesprūst.

ip link set dev wg1 mtu 1280 ir rupjais labojums, un MSS ierobežošana pārsūtītājā ir kārtīgāka. Savienojuma atkārtota mēģināšana nemaz nav labojums.

5. Pārbaudiet to kļūmi, kas jums tiešām būs

Apzināti pārtrauciet ārējo tuneli un vērojiet, kas notiek. Ķēde, kas klusi nokrīt uz tiešu ceļu, kad ārējais lēciens mirst, ir sliktāka par ķēdes neesamību, jo tā noplūst tieši tajā mirklī, kad jūs ticējāt, ka esat aizsargāts. Vēlamā uzvedība ir kill switch, kas aptur visu datplūsmu. Pierakstiet rezultātu, jo jūs negribēsiet to no jauna atklāt incidenta vidū.

Aizture un otrs kļūmes punkts ir pastāvīgās izmaksas. Divi lēcieni nozīmē arī divas atbalsta rindas, kad kaut kas salūzt neērtā stundā.