A regra dunha soa VPN en Android non bloquea un servidor SSH aloxado

A crenza é o bastante común como para tratarse como un feito: Android só permite unha VPN, así que un servidor SSH que se executa no teléfono non pode funcionar a través dese túnel. A primeira metade é certa e a conclusión non se segue. O límite da plataforma ten que ver con cantas aplicacións poden ocupar a rañura do servizo VPN, non con cantos sockets poden existir nin con quen pode conectarse ao teléfono. Un daemon SSH cun socket en escoita é unha aplicación normal cun porto normal, e o túnel é unha das rutas que pode tomar o seu tráfico.

Que limita realmente a regra dunha soa VPN

VpnService é un recurso de rañura única. Cando unha aplicación establece un túnel, convértese na VPN do dispositivo, e unha segunda aplicación que intente establecer un é rexeitada ata que a primeira desapareza. É unha regra sobre a propiedade do túnel, e explica por que dous clientes VPN non poden executarse á vez.

Non di nada sobre os sockets en escoita. O servidor SSH non chama a VpnService, non intercepta paquetes nin compite por esa rañura. Enlaza un porto e acepta conexións, que é o mesmo que faría sen ningunha VPN instalada. Así que o mito confunde un límite sobre os provedores de túnel cun límite sobre as conexións de rede, e os dous non teñen relación.

O listener é un destino, non parte do túnel

Unha vez que existe o túnel, o teléfono ten un enderezo nel e o dispositivo par ten unha ruta cara a ese enderezo. Se algo responde decídeo o listener. Un daemon enlazado a loopback só é alcanzable desde o propio teléfono; un daemon enlazado ao enderezo antigo do túnel pode conservar a súa ligazón tras unha reconexión mentres o enderezo ao que se ligou cambiou.

As regras de ligazón son configuración SSH corrente: o enderezo e o porto de escoita, e quen pode autenticarse. En Android eses axustes viven na configuración propia da aplicación, e pode que o propietario do proceso da app non teña permiso para usar portos privilexiados, de modo que o costume de escritorio de enlazar o porto 22 como root non se traslada sen cambios.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Logo está o permiso sobre a propia ruta. Unha VPN de consumo que transporta sen problema o tráfico web saínte non ten por que permitir conexións entrantes cara aos seus clientes; moitas non o fan, porque exporía un cliente ante outro. Se o par non pode alcanzar o enderezo de túnel do teléfono desde ningún sitio, o problema está na política do servizo e non no teléfono.

A ruta de resposta é onde adoita romper

Supoñamos que o par alcanza o enderezo de túnel do teléfono e o SYN chega. Agora a resposta ten que saír pola mesma ruta, e esa é unha decisión de encamiñamento dentro do teléfono. Se a resposta sae por Wi-Fi porque esa é a rede predeterminada, o par ve unha conexión que nunca se completa, o que se parece exactamente a un devasado.

Android fai isto máis complicado que un escritorio porque a rede predeterminada escóllese por proceso e a política da aplicación VPN pode cambiala. Un cliente VPN pode encamiñar só unha lista de aplicacións permitidas, así que unha aplicación servidor que queda fóra desa lista segue usando a rede física para as súas respostas mentres o par as espera polo túnel.

Unha aplicación tamén pode enlazar os seus propios sockets a unha rede concreta, o que anula a predeterminada. Cando les un informe de que un servizo é alcanzable desde un enderezo e non desde outro, normalmente este é o mecanismo que hai detrás.

Saltar a VPN non repara un servizo entrante

O recurso popular, excluír a aplicación SSH da VPN para que o seu tráfico deixe de redirixirse, é unha solución para o problema oposto. Axuda cando o transporte dun cliente SSH saínte rompe unha e outra vez por culpa do túnel. Para un servidor aloxado pode sacar as respostas do túnel que usa o par, o que converte un fallo parcial nun total.

O mesmo se aplica a abrir un porto público no router. Se o requisito é que un dispositivo autorizado chegue ao teléfono pola VPN, expor SSH a internet é un modelo de ameaza distinto e non unha reparación.

Decide primeiro o enderezo do servizo: o enderezo LAN do teléfono, o seu enderezo de túnel ou un extremo reenviado a propósito. Cada un ten o seu propio contrato de alcanzabilidade e exposición, e mesturalos é como un pequeno problema de acceso acaba convertido nun burato permanente.

Diagnostica unha dirección cada vez

Anota catro feitos antes de cambiar a configuración: o enderezo ao que se conecta o par, o estado do listener no teléfono, o contexto de aplicación e usuario que o posúe, e a ruta observada en cada dirección. Un informe que di que a VPN desconecta SSH non contén ningún deles e non pode distinguir un problema de transporte do cliente dun servidor inalcanzable.

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

Executa a comprobación do porto desde o par, non desde o teléfono, e le a saída detallada do cliente SSH para ver se falla antes ou despois do handshake TCP. Un socket que nunca conecta e un inicio de sesión rexeitado son etapas distintas con responsables distintos.

Mantén intactas a verificación da clave do host e as restricións de conta mentres depuras. Restrinxir o listener e os usuarios permitidos é o que fai aceptable un servidor alcanzable; afrouxalos para que funcione unha conexión cambia un problema por outro peor. A referencia do servidor OpenSSH cobre os controis de escoita e acceso se a túa implementación de Android segue os mesmos nomes de configuración.