Înlănțuirea a două VPN-uri: ce ascunde și cât costă

Două tuneluri imbricate nu te fac anonim. Ele împart observațiile între doi furnizori, așa că niciunul nu vede adresa ta de acasă și destinația ta în același timp. Este un beneficiu real, dar îngust, și vine cu probleme de rutare, DNS și MTU care apar prima dată când te bazezi pe el.

1. Stabilește la ce folosește al doilea salt

Scrie obiectivul într-o singură propoziție înainte de a configura ceva. Dacă scopul este ca furnizorul tău de internet să nu vadă ce site-uri vizitezi, un singur tunel ajunge. Dacă scopul este ca niciun furnizor singur să nu poată lega adresa ta de traficul tău, este nevoie de două. Dacă scopul este ca nimeni să nu te poată identifica, niciun număr de salturi nu ajunge acolo.

Lanțul este doar atât de puternic cât jurnalizarea furnizorului mai slab și înregistrările de cont pe care amândoi le păstrează. Plățile, e-mailul de înregistrare și telemetria aplicației stau complet în afara tunelului.

2. Fă punctul terminal interior accesibil prin tunelul exterior

Eșecul obișnuit este că tunelul interior nu se stabilește niciodată. O conexiune exterioară în modul tunel complet deține ruta implicită, așa că încercarea clientului interior de a-și atinge propriul punct terminal este înghițită de tunelul exterior și aruncată sau trimisă în buclă. Punctul terminal interior are nevoie de o rută explicită prin interfața exterioară, instalată înainte ca clientul interior să pornească. Altfel, handshake-ul se întrece cu ruta și pierde.

La fiecare peer, AllowedIPs decide ce destinații intră în acel tunel, așa că o interfață interioară care revendică fiecare adresă revendică și punctul terminal exterior, dacă nu câștigă o rută mai specifică. AllowedIPs suprapus pe două interfețe este o configurație în care o parte pierde în tăcere.

Înlănțuirea în containere face separarea explicită și capcana evidentă. Un container cu propriul spațiu de nume, propria rută implicită și un client în interior redirecționează ce îi trimite gazda; gazda nu începe să folosească singură acea cale. Activează forwarding-ul, adaugă o rută pentru tunelul containerului și îndreaptă serviciul spre adresa containerului.

3. Ține DNS pe aceeași cale

DNS trebuie să călătorească unde călătorește traficul. Dacă furnizorul interior împinge resolvere, iar gazda tot întreabă resolverele locale, acele interogări dezvăluie exact site-urile pe care tunelul trebuia să le ascundă. Verifică cu o captură pe fiecare interfață de tunel, în loc să te bazezi pe panoul de stare al clientului. O scurgere aici este invizibilă în navigarea normală și evidentă într-o captură.

Configurațiile cu DNS divizat fac asta mai grea, pentru că o interogare pentru un nume local poate aparține legitim în afara tunelului. Scrie lista de excepții în mod deliberat, în loc să o descoperi prin resolverul care s-a întâmplat să răspundă.

4. Setează MTU înainte ca utilizatorii să afle în locul tău

MTU este cealaltă victimă previzibilă. Două încapsulări scad două antete, iar un tunel exterior care a coborât deja MTU-ul căii lasă mai puțin spațiu înăuntru. Simptomele sunt cunoscute: cererile mici reușesc, transferurile mari și handshake-urile TLS se blochează.

ip link set dev wg1 mtu 1280 este soluția brutală, iar limitarea MSS pe forwarder este cea mai îngrijită. Reîncercarea conexiunii nu este deloc o soluție.

5. Testează eșecul pe care chiar îl vei avea

Rupere intenționat tunelul exterior și urmărește ce se întâmplă. Un lanț care cade în tăcere pe o cale directă atunci când saltul exterior moare este mai rău decât niciun lanț, pentru că scurge exact în momentul în care credeai că ești acoperit. Un kill switch care oprește tot traficul este comportamentul de urmărit. Notează rezultatul, fiindcă nu vei vrea să-l redescoperi în mijlocul unui incident.

Latența și un al doilea punct de eșec sunt costurile permanente. Două salturi înseamnă și două cozi de suport când ceva se strică la o oră incomodă.