Două salturi VPN la rând: cine vede cu adevărat traficul tău?
Salturile seriale decriptează și recriptează la prima poartă; salturile imbricate elimină doar stratul exterior. Parcurge ambele modele și vezi ce citește fiecare operator.
Fiecare profil de client numește un singur server, așa că din locul utilizatorului există un tunel și un loc unde protecția se termină. Ce se întâmplă după acea primă poartă este o decizie de proiectare pe care clientul nu o vede niciodată, iar cele două modele obișnuite se comportă foarte diferit la inspecție. Într-un lanț serial prima poartă decriptează și recriptează. Într-un lanț imbricat elimină un strat exterior și redirecționează un tunel interior pe care nu îl poate deschide. Numărul de salturi este identic în ambele, de aceea diferența trebuie desenată, nu numărată.
Începe de la client și numește ambele capete
Începe acolo unde începe utilizatorul, în profilul de conexiune. Acesta conține o adresă la distanță, o metodă de autentificare și, când proiectarea o susține, o listă de rute. Etichetează acel tunel exterior de la client la poarta A și dă-i adrese exemplu: adresa tunelului clientului 10.77.0.2, adresa lui A 10.77.0.1 și punctul final public al lui A 198.51.100.10, luate din intervalul de documentație TEST-NET-2, astfel încât nimic din exemplu să nu poată intra în conflict cu un host real.
Nimic din acel profil nu menționează poarta B, iar asta nu este un defect. Al doilea salt aparține lui A, iar singura obligație a clientului este să livreze traficul la A și să accepte ce se întoarce. Dacă A închide tunelul, îl redirecționează sau deschide unul nou este întrebarea la care răspunde restul acestei parcurgeri, iar ea decide ce poate citi A.
Serial: A decriptează, apoi recriptează
În modelul serial A închide traficul de două ori. Elimină protecția de la client, obține pachetul IP al aplicației și apoi trimite acel pachet printr-un al doilea tunel pe care A îl creează spre B. Între cele două operații pachetul stă pe calea de redirecționare a lui A ca un pachet IP obișnuit adresat unei destinații private.
Asta produce două consecințe care merită spuse direct. A poate aplica politici pachetului interior, sub formă de rute, reguli de filtrare și înregistrare a sursei și destinației, iar A trebuie să păstreze două seturi de acreditări: unul ca server pentru client și unul ca client al lui B. Protecția există în fiecare clipă, însă obiectul protejat își schimbă identitatea la A.
De aici nu rezultă că A citește textul în clar al aplicației. Când clientul și serviciul rulează TLS și își verifică reciproc certificatele, A vede un flux de înregistrări TLS, nu o cerere lizibilă. Confirmarea locului unde se termină acea protecție cere o privire la lanțul de certificate al serviciului, nu la diagrama tunelului.
Imbricat: A elimină doar stratul exterior
În modelul imbricat clientul construiește mai întâi un tunel interior spre B și apoi transportă acel tunel în interiorul celui exterior până la A. A îndepărtează antetul exterior, găsește un tunel interior și îl redirecționează fără să dețină cheile lui, așa că protecția interioară se termină tot la B.
Atunci legătura ascendentă a clientului transportă două straturi, iar calea dintre A și B transportă unul. A vede adresele exterioare ale tunelului interior, ceea ce este suficient pentru a ști că există trafic și aproximativ încotro merge, și nu este suficient pentru a citi încărcătura utilă. Aceasta este toată diferența față de cazul serial, iar niciun contor de salturi nu o arată. Ce poate face A în continuare este să refuze să redirecționeze ce nu poate citi, iar asta este mereu disponibil operatorului acelei porți.
Imbricarea plătește pentru acea proprietate. Fiecare strat adaugă suprasarcina antetului, așa că planificarea MTU și MSS devine obligatorie și nu doar ordonată, iar o cale care funcționează cu un strat poate arunca în tăcere pachete mari cu două. Fiecare strat are nevoie și de propriul comportament de reconectare și de menținere, iar o defecțiune într-un strat arată ca o întrerupere parțială prin celălalt.
Desenează observatorii, nu doar tunelurile
Tunelurile sunt partea ușoară a desenului. Observatorii sunt subiectul proiectării, așa că scrie o linie pentru fiecare punct de vedere și completează ce poate citi fiecare cu adevărat.
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
Două rânduri sunt confundate constant: operatorul lui A și furnizorul tunelului clientului. Pot fi o singură entitate, iar numele separate de poartă nu le fac independente. Proprietatea independentă cere control administrativ separat, acreditări separate și înregistrare separată.
Metadatele supraviețuiesc ambelor modele. Momentul, dimensiunile pachetelor și numărul de conexiuni rămân observabile la fiecare salt, așa că două salturi cresc costul corelării în loc să elimine semnalul. Un model care promite invizibilitate ar trebui verificat față de acea listă înainte ca cineva să se bazeze pe el.
Parcurge căile de eșec înainte de a alege
Strică lucruri intenționat de la client, în ordinea în care un utilizator le-ar întâlni. Începe cu interfața și MTU-ul ei, pentru că imbricarea eșuează la dimensiunea pachetului mult înainte de a eșua la autentificare.
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1
Apoi confirmă punctele finale de protecție în loc să le presupui. Cere serviciului certificatul său din interiorul tunelului care este activ și compară lanțul pe care clientul îl vede cu lanțul pe care serviciul îl prezintă efectiv. O poartă care resemnează sau interceptează schimbă acel certificat, iar inspecția devine vizibilă într-o singură comandă.
openssl s_client -connect intranet.example.com:443 -brief < /dev/null
Încheie cu matricea de reconectare: tunelul clientului cade, tunelul lui B cade, calea dintre A și B se schimbă. Notează ce revine și ce nu, și dacă o conexiune interioară cade vreodată pe o rută din afara transportatorului prevăzut. Înregistrează adresele folosite de fiecare test, pentru că repetarea pe altă rețea de acces răspunde la altă întrebare. Repetă și testul MTU după fiecare reconectare, pentru că o cale schimbată poate coborî dimensiunea utilizabilă fără ca vreo linie de configurare să se miște.
Alege serial când A trebuie să aplice politici pachetului interior, sau când clientul nu poate rula două tuneluri suprapuse. Alege imbricarea când încărcătura interioară trebuie să rămână ilizibilă la A. Scrie alegerea cu observatorii ei și cu cifrele ei de MTU, iar următoarea persoană nu va trebui să redeseneze tot tabloul pentru a răspunde la o întrebare.