La regla d'una sola VPN d'Android no bloqueja un servidor SSH allotjat

La creença és prou estesa per tractar-se com un fet: Android només permet una VPN, així que un servidor SSH al telèfon no pot funcionar per aquest túnel. La primera meitat és certa i la conclusió no se'n segueix. El límit de la plataforma tracta de quantes aplicacions poden ocupar la ranura del servei VPN, no de quants sockets poden existir ni de qui pot connectar-se al telèfon. Un dimoni SSH amb un socket d'escolta és una aplicació corrent amb un port corrent, i el túnel és un dels camins que pot prendre el seu trànsit.

Què limita realment la regla d'una sola VPN

VpnService és un recurs d'una sola ranura. Quan una aplicació estableix un túnel es converteix en la VPN del dispositiu, i una segona aplicació que intenti establir-ne un és rebutjada fins que la primera desaparegui. És una regla sobre la propietat del túnel, i explica per què dos clients VPN no poden funcionar alhora.

No diu res sobre els sockets d'escolta. El servidor SSH no crida VpnService, no intercepta paquets ni competeix per aquesta ranura. Lliga un port i accepta connexions, que és el mateix que faria sense cap VPN instal·lada. El mite confon un límit als proveïdors de túnel amb un límit a les connexions de xarxa, i els dos no tenen cap relació.

L'oient és una destinació, no part del túnel

Un cop existeix el túnel, el telèfon hi té una adreça i el dispositiu parell té una ruta cap a aquesta adreça. Si alguna cosa respon ho decideix l'oient. Un dimoni lligat a loopback només és abastable des del mateix telèfon; un dimoni lligat a l'adreça antiga del túnel pot mantenir la lligadura després de reconnectar encara que l'adreça hagi canviat.

Les regles de lligadura són configuració SSH corrent: l'adreça i el port d'escolta, i qui pot autenticar-se. A Android aquests paràmetres viuen a la configuració de la mateixa aplicació, i el propietari del procés pot no tenir permís per usar ports privilegiats, així que el costum d'escriptori de lligar el port 22 com a root no es trasllada sense canvis.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Després hi ha el permís al mateix camí. Una VPN de consum que porta de bon grat trànsit web de sortida no ha de permetre cap connexió d'entrada cap als seus clients; moltes no ho fan, perquè exposaria un client a un altre. Si el parell no pot arribar a l'adreça del telèfon al túnel des de cap lloc, el problema és a la política del servei, no al telèfon.

El camí de resposta és on normalment es trenca

Suposem que el parell arriba a l'adreça del telèfon al túnel i el SYN arriba. Ara la resposta ha de sortir pel mateix camí, i això és una decisió d'encaminament dins del telèfon. Si la resposta surt per Wi-Fi perquè és la xarxa per defecte, el parell veu una connexió que no s'acaba mai, cosa que sembla exactament un tallafoc.

Android ho fa més complicat que un escriptori perquè la xarxa per defecte es tria per procés i la política de l'aplicació VPN la pot canviar. Un client VPN només pot encaminar una llista d'aplicacions permeses, així que una aplicació servidor fora d'aquesta llista continua usant la xarxa física per a les seves respostes mentre el parell les espera pel túnel.

Una aplicació també pot lligar els seus sockets a una xarxa concreta, cosa que substitueix el valor per defecte. Quan llegiu un informe que un servei és abastable des d'una adreça i no des d'una altra, normalment aquest és el mecanisme que hi ha darrere.

Evitar la VPN no repara un servei d'entrada

La solució popular, excloure l'aplicació SSH de la VPN perquè el seu trànsit deixi de ser redirigit, és una reparació del problema oposat. Ajuda quan el transport d'un client SSH de sortida es trenca constantment pel túnel. Per a un servidor allotjat pot moure les respostes fora del túnel que el parell utilitza, i això converteix un fracàs parcial en un de total.

El mateix val per obrir un port públic al router. Si el requisit és que un dispositiu autoritzat arribi al telèfon per la VPN, exposar SSH a internet és un model d'amenaça diferent i no una reparació.

Decidiu primer l'adreça del servei: l'adreça LAN del telèfon, la seva adreça al túnel o un punt final desviat expressament. Cadascuna té el seu contracte d'abastabilitat i exposició, i barrejar-los és com un petit problema d'accés es converteix en un forat permanent.

Diagnostica un sentit alhora

Anoteu quatre fets abans de canviar la configuració: l'adreça a la qual es connecta el parell, l'estat de l'oient al telèfon, el context d'aplicació i usuari que el posseeix, i el camí observat en cada sentit. Un informe que diu que la VPN talla SSH no conté cap d'ells i no pot distingir un problema de transport del client d'un servidor inabastable.

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

Feu la comprovació del port des del parell, no des del telèfon, i llegiu la sortida detallada del client SSH per veure si falla abans o després de l'encaixada TCP. Un socket que no connecta mai i un inici de sessió rebutjat són etapes diferents amb propietaris diferents.

Manteniu intactes la verificació de clau d'amfitrió i les restriccions de compte mentre depureu. Limitar l'oient i els usuaris permesos és el que fa acceptable un servidor abastable; afluixar-los perquè una connexió funcioni canvia un problema per un de pitjor. La referència del servidor OpenSSH cobreix els controls d'escolta i accés si la vostra implementació d'Android segueix els mateixos noms de configuració.