Lančano povezivanje dva VPN-a: šta skriva i koliko košta
Ugniježđeni tuneli mijenjaju to ko vidi koje krajnje tačke, a ne to ko vidi vas. Provedite unutrašnju krajnju tačku kroz vanjski tunel, pa provjerite DNS, MTU i ponašanje pri otkazu.
Dva ugniježđena tunela ne čine vas anonimnim. Oni dijele zapažanja između dva provajdera, pa nijedan ne vidi istovremeno vašu kućnu adresu i vaše odredište. To je stvarna, ali uska prednost, i dolazi s problemima rutiranja, DNS-a i MTU-a koji se pojave prvi put kada se na nju oslonite.
1. Odlučite čemu služi drugi skok
Zapišite cilj u jednoj rečenici prije nego što bilo šta konfigurišete. Ako je cilj da vaš ISP ne vidi koje stranice posjećujete, jedan tunel to postiže. Ako je cilj da nijedan provajder sam ne može povezati vašu adresu s vašim saobraćajem, potrebna su dva. Ako je cilj da vas niko ne može identifikovati, nijedan broj skokova tamo ne vodi.
Lanac je jak onoliko koliko je jako logovanje slabijeg provajdera i evidencija naloga koju oba vode. Plaćanja, e-pošta pri registraciji i telemetrija aplikacije stoje potpuno izvan tunela.
2. Učinite unutrašnju krajnju tačku dostupnom kroz vanjski tunel
Uobičajeni kvar je da se unutrašnji tunel nikada ne uspostavi. Vanjska veza u režimu punog tunela posjeduje zadanu rutu, pa pokušaj unutrašnjeg klijenta da dosegne sopstvenu krajnju tačku biva progutan od vanjskog tunela i odbačen ili završi u petlji. Unutrašnjoj krajnjoj tački treba izričita ruta kroz vanjski interfejs, ugrađena prije nego što se unutrašnji klijent pokrene. Inače se rukovanje trka s rutom i gubi.
WireGuard pokazuje isti sukob iz drugog smjera. Kod svakog peera AllowedIPs odlučuje koja odredišta ulaze u taj tunel, pa unutrašnji interfejs koji traži svaku adresu traži i vanjsku krajnju tačku, osim ako pobijedi specifičnija ruta. Preklapajući AllowedIPs na dva interfejsa je konfiguracija u kojoj jedna strana tiho gubi.
Lančanje kontejnera čini razdvajanje jasnim, a zamku očiglednom. Kontejner sa sopstvenim imenskim prostorom, sopstvenom zadanom rutom i klijentom unutra prosljeđuje ono što mu host pošalje; host sam ne počinje koristiti taj put. Uključite prosljeđivanje, dodajte rutu za tunel kontejnera i usmjerite uslugu na adresu kontejnera.
3. Držite DNS na istom putu
DNS mora putovati tamo kuda putuje saobraćaj. Ako unutrašnji provajder gura rezolvere, a host i dalje pita lokalne, ti upiti otkrivaju tačno one stranice koje je tunel trebalo da sakrije. Provjeravajte snimkom na svakom interfejsu tunela umjesto da vjerujete statusnom panelu klijenta. Curenje ovdje je nevidljivo tokom običnog pregledanja, a očigledno u snimku.
Podijeljeni DNS dizajni ovo otežavaju, jer upit za lokalno ime može legitimno pripadati izvan tunela. Napišite listu izuzetaka namjerno, umjesto da je otkrijete preko rezolvera koji je slučajno odgovorio.
4. Postavite MTU prije nego što korisnici otkriju umjesto vas
MTU je druga predvidiva žrtva. Dvije enkapsulacije oduzimaju dva zaglavlja, a vanjski tunel koji je već snizio MTU puta ostavlja manje prostora unutra. Simptomi su poznati: mali zahtjevi prolaze, veliki prenosi i TLS rukovanja se zaglave.
ip link set dev wg1 mtu 1280 je grubo rješenje, a stezanje MSS-a na prosljeđivaču je urednije. Ponovni pokušaj veze nije nikakvo rješenje.
5. Testirajte kvar koji ćete zaista dobiti
Namjerno slomite vanjski tunel i gledajte šta se dešava. Lanac koji tiho padne na direktan put kada vanjski skok umre gori je od nikakvog lanca, jer curi tačno u trenutku kada ste vjerovali da ste pokriveni. Kill switch koji zaustavlja sav saobraćaj je ponašanje kojem treba težiti. Zapišite rezultat, jer ga nećete htjeti ponovo otkrivati usred incidenta.
Kašnjenje i druga tačka otkaza su stalni troškovi. Dva skoka znače i dva reda podrške kada se nešto pokvari u nezgodan čas.