Split tunneling după aplicație sau după destinație: ce să alegeți

Split tunneling după aplicație și după destinație nu sunt două setări pentru aceeași sarcină. Unul întreabă ce proces trimite un pachet; celălalt întreabă unde merge acel pachet. O regulă construită pentru prima întrebare eșuează în tăcere când traficul vine dintr-un proces auxiliar, iar o regulă construită pentru a doua eșuează când un nume de gazdă se rezolvă la o adresă pe care nu ați listat-o niciodată. Alegeți obiectul care corespunde cerinței și dovediți-l cu două pachete de test: unul care trebuie să folosească tunelul și unul care nu trebuie.

Cele două reguli acționează la niveluri diferite

O regulă de aplicație se aplică deasupra nivelului de rețea, față de identitatea pe care sistemul de operare o atribuie expeditorului. Pe Android aceea este UID-ul din spatele unui pachet, iar serviciul VPN decide pentru fiecare UID dacă traficul intră în tunel. Despre destinație nu se întreabă nimic, așa că aplicația selectată poate atinge orice, iar nicio altă aplicație nu poate atinge rețeaua internă.

O regulă de destinație se aplică pe pachetul însuși. Interfața tunelului posedă un set de prefixe, tabela de rutare trimite acolo traficul potrivit, iar procesul care trimite este irelevant. De aceea o regulă de destinație acoperă un serviciu, o imprimantă sau o sarcină batch pe care nimeni nu și-a amintit să o listeze, și de aceea nu poate fi exprimată ca exact acest program pe o platformă al cărei client nu se uită niciodată la proces.

Regulile de aplicație se potrivesc clienților mobili și agenților gestionați

Android expune alegerea direct: VpnService.Builder.addAllowedApplication() și addDisallowedApplication() preiau nume de pachete și aplică decizia pentru fiecare UID, cum se descrie în ghidul pentru dezvoltatori VPN al Android. iOS are un echivalent prin reguli VPN pentru fiecare aplicație, bazate pe identificatori de pachet, de obicei livrate printr-un profil MDM și nu tastate manual.

Clienții desktop sunt punctul slab. Majoritatea clienților VPN pentru Windows și macOS rutează după destinație și nu oferă niciun selector pe proces, pentru că driverul tunelului vede pachete, nu procese. Dacă planul dvs. depinde de tunelarea unei singure aplicații pe un laptop, verificați capacitățile reale ale clientului înainte de a proiecta în jurul lor; poate alegeți între o listă de destinații și o a doua mașină.

Un corolar pe care oamenii îl ratează: pe acele platforme nu puteți imita o regulă de aplicație cu rute. Adăugarea unei rute de gazdă pentru serverul aplicației tunelează traficul tuturor către acel server, inclusiv browserul și programul de actualizare.

Regulile de destinație se potrivesc listelor de subrețele și accesibilității site-urilor

WireGuard face modelul explicit. AllowedIPs este rutare pe cheie criptografică: un pachet interior a cărui destinație cade în lista unui peer este criptat către acel peer, iar orice altceva iese necriptat pe calea normală. Nu există niciun proces de numit și nicio ambiguitate cu privire la ce este inclus.

OpenVPN ajunge în același loc prin tabela de rutare împinsă. route-nopull împiedică serverul să dicteze rute, iar după aceea un route 10.20.0.0 255.255.0.0 vpn_gateway pe partea clientului acoperă exact prefixul biroului. IPv6 este o instrucțiune separată în fiecare dintre acești clienți, iar uitarea ei este cea mai frecventă cale de scurgere în jurul unei separări IPv4 care pare corectă.

Un nume de gazdă nu este o rută. Dacă profilul oferă un câmp de domeniu, tratați-l ca un nume pe care clientul îl rezolvă o dată, nu ca un interval permanent de adrese; rețelele de distribuție a conținutului și balansoarele de încărcare vor da mâine alte adrese.

Unde se rup ambele modele: auxiliare, servicii partajate, rezolvatoare

Procesele auxiliare strică regulile de aplicație într-un mod care arată ca o defecțiune a serverului. Actualizatorul unui browser, un raportor de erori, un serviciu de sincronizare care rulează ca SYSTEM și un WebView încorporat într-un alt pachet sunt identități separate, așa că tunelarea browserului poate lăsa cererea reală în afara tunelului. Inversul este la fel de confuz: o aplicație exclusă care apelează o bibliotecă partajată în interiorul unui proces tunelat are în continuare traficul prin tunel.

Regulile de destinație se rup pe servicii partajate și pe nume. Partajările de fișiere, imprimantele, DNS-ul intern și serverul de licențe trăiesc la adrese, așa că un tunel pentru o singură aplicație dă browserului acces în timp ce unitatea mapată rămâne moartă. Această diferență de acoperire nu este un defect al niciunui model, dar este motivul pentru care un tunel pentru o singură aplicație produce atât de des situația în care VPN-ul este pornit și partajarea a dispărut.

Rezolvatoarele taie ambele. Dacă clientul setează servere DNS interne, dar sistemul de operare folosește DNS prin HTTPS către un rezolvator public, răspunsul vine din afara tunelului și regula de destinație poate să nu se potrivească niciodată. Verificați ce rezolvator a răspuns efectiv înainte de a concluziona că regula este greșită și confirmați pe partea clientului dacă a instalat rezolvatorul tunelului. O separare care lasă DNS-ul în afara tunelului arată perfect în tabela de rutare și tot eșuează la fiecare nume intern.

Procedură: alege, aplică, verifică

Începeți de la cerință, nu de la meniu. Dacă scopul este ca doar această aplicație să poată folosi tunelul, aveți nevoie de reguli de aplicație și de o platformă care le acceptă. Dacă scopul este ca aceste rețele să fie accesibile prin tunel, aveți nevoie de prefixe. Dacă răspunsul este ambele, implementați-le ca două controale separate și notați care este responsabil de ce eșec.

Aplicați cea mai îngustă formă pe care o puteți exprima, apoi verificați întrebând tabela de rutare în locul pictogramei de stare a clientului:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Primele două linii numesc interfața pe care ar folosi-o o destinație reală; wg show afișează lista de prefixe configurată; pe Windows, Find-NetRoute răspunde la aceeași întrebare la care va răspunde stiva când pachetul este trimis. Dacă interfața este tunelul, regula s-a potrivit.

Apoi testați un al doilea pachet care ar trebui exclus, din altă aplicație, către aceeași destinație. Notați în tichet versiunea clientului, tipul regulii, lista de prefixe sau de pachete și cele două rezultate observate. Exact această pereche de rezultate îi spune următorului inginer dacă politica este configurată greșit sau dacă traficul nu i-a aparținut niciodată.