Cum tunelul divizat decide ce trafic folosește VPN-ul

Tunelul divizat este o politică de rutare exprimată ca un set de reguli, și clientul este doar ceea ce le instalează. Separarea are loc în două locuri: reguli de potrivire care aleg o cale pentru fiecare pachet, și legături care țin o aplicație pe o singură interfață orice ar spune tabelul. Pe ce mecanism se bazează clientul tău explică majoritatea surprizelor pe care le raportează oamenii.

O politică pe care o poți enunța într-o singură linie este testabilă. O politică descrisă ca navigare mai rapidă nu este, și nu îți va spune ce regulă să schimbi când o cerere merge în direcția greșită.

Clientul instalează reguli, nucleul face alegerea

Când tunelul urcă, clientul adaugă rute și adesea reguli de politică în același tabel pe care îl folosesc celelalte interfețe ale tale. Fiecare pachet ajunge apoi la o căutare care compară destinația cu fiecare prefix candidat și păstrează potrivirea cea mai specifică, în timp ce prioritatea rezolvă egalitățile între reguli care indică tabele diferite. Nimic din acea căutare nu știe că pachetul a venit dintr-o filă de browser și nu dintr-o sarcină de backup. Regula care câștigă este cea care stabilește calea, și o poți citi înainte și după schimbare.

De aceea un tunel divizat poate părea arbitrar. Două destinații într-o singură aplicație pot lua căi diferite doar pentru că un prefix este mai îngust decât celălalt.

Aceeași alegere există pe fiecare platformă, deși numele se schimbă. Windows împinge decizia în platforma sa de filtre, Android expune o listă de permisiuni pe aplicație prin serviciul său VPN, iar macOS leagă tunelul de un dispozitiv care încă ascultă de tabelul de rutare. Notele de rutare ale Microsoft merită citite pentru cazul Windows, iar un ghid scris pentru o platformă se transferă rar fără modificări pe alta.

Legarea pe aplicație și prefixele de destinație sunt instrumente diferite

O politică de destinație întreabă încotro merge pachetul și consultă tabelul de rute sau o regulă de politică. O politică pe aplicație întreabă ce program a deschis socketul, iar platforma ține acel program pe interfața tunelului chiar și când o rută mai specifică indică altundeva. A doua este mai puternică pentru că supraviețuiește schimbărilor de tabel, dar acoperă doar procesele pe care platforma le poate atribui. Un proces auxiliar, un browser încorporat sau un serviciu care își deschide propria conexiune poate să nu moștenească legătura pe care ai presupus-o.

Niciuna dintre cele două abordări nu supraviețuiește unei politici bazate pe nume fără ajutor. Adresele site-urilor mari se rotesc între rețele de conținut, așa că fixarea unui nume de gazdă la câteva prefixe produce o regulă care încetează în tăcere să se potrivească. O politică ce trebuie să urmeze nume are nevoie de o componentă conștientă de resolver în locul unei rute statice.

DNS-ul și întrerupătorul de siguranță urmează propriile reguli

Rezolvarea numelor este o decizie separată de rutarea pachetelor, iar un tunel divizat vrea de obicei doi resolveri: cel al companiei pentru nume interne, cel local pentru restul. Clientul poate instala setări DNS pe interfață, poate preda interogările unui resolver intermediar sau poate lăsa valoarea implicită a sistemului neatinsă. Un browser cu propriul resolver criptat ocolește toate trei aranjamentele. Testează o căutare în loc să presupui că resolverul a urmat ruta.

Un întrerupător de siguranță adaugă un filtru deasupra, iar acel filtru nu distinge întotdeauna o excludere intenționată de o scurgere accidentală. Unii clienți blochează tot ce este în afara tunelului, în timp ce alții permit excluderile declarate de politică, așa că citește ce comportament implementează al tău înainte să te bazezi pe oricare dintre ele.

Verifică divizarea din ambele părți

Testează separat calea inclusă și calea exclusă, și judecă rezultatul după numele interfeței, nu după o adresă publică. Aceste comenzi presupun un gazdă Linux cu dispozitivul tunelului deja ridicat. Înlocuiește 203.0.113.10 cu o destinație pe care politica ta o rutează înăuntru, și 198.51.100.25 cu una pe care o trimite în afară.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Citește primele două răspunsuri împreună, pentru că interfața numită în fiecare arată dacă divizarea a pus acea destinație pe tunel. Interogarea resolverului arată ce server a răspuns la numele intern, iar ultima comandă dovedește că dispozitivul tunelului poate transporta o cerere. Un eșec pe a doua linie în timp ce prima reușește înseamnă că politica face exact ce i s-a spus.

Repetă setul după o reconectare și după o schimbare de rețea. Reînnoirea bailului și mișcarea interfețelor sunt locurile unde o divizare încetează să corespundă intenției pentru care a fost construită, iar o ieșire salvată din fiecare rulare face derivarea evidentă.