Deschiderea unui al doilea browser nu creează o a doua rută VPN

Două browsere, două ferestre, una pe contul de serviciu și cealaltă pe un cont personal, iar presupunerea este că acum urmează căi diferite. Nu fac asta. Separarea profilurilor ține cookie-urile deoparte, în timp ce decizia de rutare se ia sub browser și nu știe ce profil a întrebat. O a doua cale are nevoie de o regulă care o selectează, iar locurile în care o astfel de regulă poate locui sunt foarte puține.

Separarea stării nu este separarea căii

Un profil de browser izolează stocarea: cookie-uri, istoric, extensii și uneori date de autentificare. Acea izolare este impusă în interiorul unui singur arbore de procese și nu are nimic de spus despre ce interfață transportă un pachet.

Ferestrele private merg mai departe în aspect și nici un pas mai departe în rutare. Tot ce trimite browserul iese în continuare pe calea aleasă de sistemul de operare, dacă ceva între socket și rețea nu o schimbă. Confundarea izolării stocării cu izolarea rețelei creează așteptări pe care niciun producător de browsere nu le-a promis și pe care niciun test nu le poate satisface.

Ce selectează de fapt o rută

Patru lucruri pot selecta o cale diferită: o regulă VPN pentru fiecare aplicație care corespunde executabilului sau pachetului, un proxy configurat în browser sau în sistem, un spațiu de nume de rețea sau un container, și un al doilea dispozitiv fizic. Fiecare schimbă ceva real, și fiecare are costul său.

O regulă pentru fiecare aplicație este răspunsul obișnuit pe platformele mobile, unde serviciul VPN primește o listă de pachete. Pe desktop depinde de client, iar o regulă care corespunde executabilului acoperă fiecare profil pe care acel executabil îl deschide. Dacă două profiluri au într-adevăr nevoie de căi diferite, de obicei au nevoie de două procese cu identități diferite în loc de două file. De aceea o instalare partajată a browserului nu poate fi niciodată granița într-un design pe profiluri.

Proxy-urile la nivel de aplicație adaugă încă un intermediar

O setare de proxy în browser creează într-adevăr o cale separată și creează totodată o relație de încredere separată cu cine operează proxy-ul. Este o soluție legitimă pentru un profil și nu este echivalentă cu o acoperire a întregului dispozitiv.

Alegeți proxy-ul deliberat: un ascultător SOCKS pe aceeași gazdă, un proxy autentificat în interiorul tunelului sau un serviciu la distanță. Amestecarea unui proxy cu un VPN cu tunel complet produce căi imbricate în care modurile de eșec se înmulțesc.

Verificați cererea reală a fiecărui browser

Trimiteți aceeași cerere din fiecare browser și comparați adresa de ieșire observată, în loc să comparați paginile de setări. Un proxy configurat care eșuează în liniște la conectare este o modalitate foarte comună de a ajunge înapoi pe calea implicită.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

Apoi repetați cererea cu proxy-ul forțat și cu tunelul oprit, pentru a vedea ce strat transportă de fapt traficul. Notați și răspunsul DNS, pentru că un browser cu propriul său resolver criptat poate ocoli complet calea sistemului și totuși afișa pagina la care vă așteptați.

Scrieți corespondența dorită în două rânduri: ce proces folosește ce cale și cine deține fiecare. Aveți în vedere și identitățile conturilor, pentru că două căi nu împiedică aceeași autentificare să fie prezentată ambelor destinații. Retestați după următoarea actualizare a browserului, pentru că o setare de proxy se pierde ușor și se observă greu.