Regula unui singur VPN în Android nu blochează un server SSH găzduit

Această convingere este suficient de răspândită încât să fie tratată ca un fapt: Android permite un singur VPN, așa că un server SSH care rulează pe telefon nu poate funcționa prin acel tunel. Prima jumătate este adevărată, iar concluzia nu decurge din ea. Limita platformei se referă la câte aplicații pot ocupa locul serviciului VPN, nu la câte socketuri pot exista sau cine are voie să se conecteze la telefon. Un demon SSH cu un socket în ascultare este o aplicație obișnuită cu un port obișnuit, iar tunelul este una dintre căile pe care poate merge traficul său.

Ce limitează de fapt regula unui singur VPN

VpnService este o resursă cu un singur loc. Când o aplicație stabilește un tunel, devine VPN-ul dispozitivului, iar o a doua aplicație care încearcă să stabilească unul este refuzată până când prima dispare. Este o regulă despre proprietatea tunelului și explică de ce doi clienți VPN nu pot rula simultan.

Nu spune nimic despre socketurile în ascultare. Serverul SSH nu apelează VpnService, nu interceptează pachete și nu concurează pentru acel loc. Leagă un port și acceptă conexiuni, exact ceea ce ar face fără niciun VPN instalat. Așadar mitul confundă o limită privind furnizorii de tuneluri cu o limită privind conexiunile de rețea, iar cele două nu au nicio legătură.

Listenerul este o destinație, nu parte a tunelului

Odată ce tunelul există, telefonul are o adresă pe el, iar dispozitivul partener are o rută către acea adresă. Dacă răspunde ceva este decis de listener. Un demon legat de loopback este accesibil doar din telefonul însuși; un demon legat de adresa veche a tunelului poate păstra legătura după o reconectare, deși adresa de care s-a legat s-a schimbat.

Regulile de legare sunt configurație SSH obișnuită: adresa și portul de ascultare și cine se poate autentifica. În Android aceste setări se află în configurația aplicației înseși, iar proprietarul procesului aplicației poate să nu aibă voie să folosească porturi privilegiate, așa că obiceiul de desktop de a lega portul 22 ca root nu se transferă neschimbat.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Apoi este permisiunea pe calea însăși. Un VPN de consum care transportă bucuros trafic web de ieșire nu trebuie să permită deloc conexiuni de intrare către clienții săi; multe nu o fac, pentru că ar expune un client altuia. Dacă partenerul nu poate ajunge la adresa de tunel a telefonului de nicăieri, problema stă în politica serviciului, nu în telefon.

Calea de răspuns este locul unde de obicei se rupe

Să presupunem că partenerul ajunge la adresa de tunel a telefonului și sosește SYN. Acum răspunsul trebuie să iasă pe aceeași cale, iar aceasta este o decizie de rutare în interiorul telefonului. Dacă răspunsul iese prin Wi-Fi pentru că aceea este rețeaua implicită, partenerul vede o conexiune care nu se finalizează niciodată, ceea ce arată exact ca un firewall.

Android face acest lucru mai complicat decât un desktop pentru că rețeaua implicită este aleasă pe proces și poate fi schimbată de politica aplicației VPN. Un client VPN poate ruta doar o listă de aplicații permise, așa că o aplicație server din afara acelei liste continuă să folosească rețeaua fizică pentru răspunsurile sale, în timp ce partenerul le așteaptă prin tunel.

O aplicație poate, de asemenea, să își lege propriile socketuri de o rețea anume, ceea ce anulează valoarea implicită. Când citiți un raport că un serviciu este accesibil de la o adresă și nu de la alta, de obicei acesta este mecanismul din spate.

Ocolirea VPN nu repară un serviciu de intrare

Soluția populară, excluderea aplicației SSH din VPN astfel încât traficul ei să nu mai fie redirecționat, este o corecție pentru problema opusă. Ajută atunci când transportul unui client SSH de ieșire se rupe continuu din cauza tunelului. Pentru un server găzduit poate scoate răspunsurile din tunelul pe care îl folosește partenerul, ceea ce transformă o defecțiune parțială într-una totală.

Același lucru se aplică deschiderii unui port public pe router. Dacă cerința este ca un singur dispozitiv autorizat să ajungă la telefon prin VPN, expunerea SSH la internet este un alt model de amenințare și nu o reparație.

Decideți mai întâi adresa serviciului: adresa LAN a telefonului, adresa sa de tunel sau un endpoint redirecționat intenționat. Fiecare are propriul contract de accesibilitate și expunere, iar amestecarea lor este felul în care o mică problemă de acces devine o gaură permanentă.

Diagnosticați o singură direcție o dată

Notați patru fapte înainte de a schimba configurația: adresa la care se conectează partenerul, starea listenerului pe telefon, contextul de aplicație și utilizator care îl deține și calea observată în fiecare direcție. Un raport care spune că VPN-ul deconectează SSH nu conține niciunul dintre ele și nu poate distinge o problemă de transport a clientului de un server inaccesibil.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Rulați verificarea portului de la partener, nu de la telefon, și citiți ieșirea detaliată a clientului SSH pentru a vedea dacă eșuează înainte sau după handshake-ul TCP. Un socket care nu se conectează niciodată și o autentificare refuzată sunt etape diferite cu responsabili diferiți.

Păstrați neatinse verificarea cheii gazdă și restricțiile de cont în timp ce faceți depanarea. Tocmai limitarea listenerului și a utilizatorilor permise face un server accesibil acceptabil; relaxarea lor pentru ca o conexiune să funcționeze schimbă o problemă cu una mai rea. Referința serverului OpenSSH acoperă controalele de ascultare și acces dacă implementarea dvs. Android urmează aceleași nume de configurare.