Tunelarea divizată pentru clienții hotspot nu este excludere pe aplicație

Două cerințe care sună la fel nu sunt la fel: „exclude această aplicație din VPN” și „trimite această singură destinație în afara VPN pentru laptopul de pe hotspotul meu”. Prima schimbă modul în care un socket de pe telefon alege o rețea. A doua trebuie să schimbe o decizie de redirecționare pentru un pachet care a venit de la alt dispozitiv după ce telefonul l-a acceptat deja. Confundarea celor două este modul în care un client hotspot ajunge cu o excepție care s-a aplicat mereu doar browserului telefonului însuși.

Două subsisteme dețin cele două întrebări

Android ține separate rețeaua aplicațiilor și partajarea conexiunii. Socketurile aplicațiilor sunt atribuite unei rețele de stiva de conectivitate, iar o aplicație VPN decide care dintre socketurile sale intră în tunel. Pachetele redirecționate de la un client conectat sunt tratate de subsistemul de partajare, care cere de la netd rute, reguli de politică și traducere pe interfața din aval.

Excluderea pe aplicație este evaluată când o aplicație deschide un socket. Un pachet redirecționat nu ajunge niciodată la acea verificare, pentru că nu a provenit dintr-un socket de aplicație de pe acest dispozitiv. Acesta este tot motivul pentru care cele două setări nu se pot înlocui reciproc, și nu este un defect în niciuna dintre ele.

Ce schimbă de fapt excluderea pe aplicație

Un constructor VpnService poate numi pachetele care rămân în afara tunelului cu addDisallowedApplication, sau poate numi singurele pachete permise în interior cu addAllowedApplication. Acele aplicații deschid apoi socketuri pe rețeaua de bază în timp ce VPN-ul deține în continuare ruta implicită pentru tot restul.

Domeniul este precis: socketurile proprii ale pachetului, pe acest dispozitiv, cât timp tunelul este activ. Nu spune nimic despre traficul redirecționat, nimic despre un al doilea dispozitiv și nimic despre pachetele pe care sistemul le trimite în numele partajării.

Nu este nici un control al destinației. Excluderea unui browser exclude fiecare adresă pe care o atinge acel browser, inclusiv pe cea pe care voiai să o păstrezi în tunel. Când cerința numește o destinație în loc de o aplicație, selectorul de aplicații este instrumentul greșit prin construcție.

Cum arată un pachet partajat pentru telefon

Pachetul clientului ajunge pe interfața hotspot cu o adresă de sursă privată atribuită de telefon, să zicem 192.168.43.20, și cu o destinație publică. Pentru a-l redirecționa, telefonul are nevoie de o rută către o legătură superioară și de o regulă de traducere pentru ca răspunsurile să găsească drumul înapoi, fiindcă adresa privată a clientului nu înseamnă nimic în rețeaua celulară.

Android exprimă asta prin reguli de politică ce selectează un tabel de rutare, iar netd reconstruiește tabelele și regulile relevante când rețelele și VPN-urile se schimbă. Un număr de tabel, o prioritate de regulă sau un nume de interfață copiate dintr-o postare de forum, sau de la același model într-o versiune mai veche, nu stabilesc o proprietate durabilă. Această reconstrucție este și motivul pentru care o regulă scrisă de mână poate funcționa o oră și se poate opri după următoarea reconectare.

De ce politică are nevoie de fapt o excepție de hotspot

Scrie decizia ca sursă, destinație și cale intenționată înainte de a atinge o regulă. Forma minimă pentru o destinație aprobată arată astfel:

Ambele direcții trebuie să fie complete. Ramura directă are nevoie de o rută utilizabilă prin legătura superioară celulară care se întâmplă să fie actuală; ramura VPN are nevoie de ruta tunelului plus permisiunea de a redirecționa. Orice traducere de sursă trebuie să corespundă ieșirii alese, fiindcă NAT aplicat pe o interfață de tunel arată adresa tunelului și nu pe cea celulară, iar calea de întoarcere nu mai concorda atunci cu calea de ducere.

Răspunsurile trebuie să ajungă la același client din aval prin stare urmărită sau printr-o rută explicită, iar un contor de pachete de ieșire nu dovedește nimic din asta. Ține și transportul exterior propriu al VPN-ului în afara domeniului excepției, altfel pachetele purtătoare ale tunelului moștenesc o politică scrisă pentru o cerere web a unui client.

O adresă capturată nu este o destinație

O singură adresă IPv4 citită dintr-un browser este o instantanee. Serviciile mari răspund din anycast sau dintr-un set rotativ de adrese de margine, multe sunt cu stivă dublă, iar un flux de autentificare poate atinge gazde de autentificare și telemetrie pe care pagina nu le arată niciodată. O excepție construită în jurul adresei pe care ai văzut-o din întâmplare se strică data viitoare când serviciul reechilibrează.

Folosește adresele documentate ale proprietarului serviciului, sau un interval pe care îl publică, și ia în calcul ambele familii de adrese. Dacă cerința nu poate fi exprimată ca un set stabil, este probabil o întrebare de politică pentru serviciu și nu un truc de rutare pe un telefon.

Verifică din partea din aval

Trei verificări, în această ordine: serviciul ales de pe laptop, o destinație obișnuită care trebuie să rămână în VPN și o aplicație a telefonului care trebuie să rămână neatinsă. Apoi repetă după o reconectare și după o schimbare a legăturii superioare, fiindcă atunci se reconstruiesc tabelele de politică.

Dacă implementarea de partajare a telefonului nu poate ține acel contract pe parcursul unei reconectări, mută politica selectivă pe un router din aval acceptat, în loc să aduni reguli root pe dispozitiv. Un router poate exprima potrivirea sursei și a destinației cu un proprietar stabil, iar documentația modulului de partajare este referința corectă pentru ce face telefonul de fapt.