La regola del VPN unico su Android non blocca un server SSH ospitato

La convinzione è abbastanza diffusa da essere trattata come un fatto: Android consente un solo VPN, quindi un server SSH in esecuzione sul telefono non può funzionare attraverso quel tunnel. La prima metà è vera e la conclusione non ne segue. Il limite della piattaforma riguarda quante app possono occupare lo slot del servizio VPN, non quanti socket possono esistere né chi può connettersi al telefono. Un demone SSH con un socket in ascolto è un'app normale con una porta normale, e il tunnel è una delle vie che il suo traffico può prendere.

Che cosa limita davvero la regola del VPN unico

VpnService è una risorsa a slot singolo. Quando un'app stabilisce un tunnel diventa il VPN del dispositivo, e una seconda app che prova a stabilirne uno viene rifiutata finché la prima non scompare. È una regola sulla proprietà del tunnel, e spiega perché due client VPN non possono funzionare contemporaneamente.

Non dice nulla sui socket in ascolto. Il server SSH non chiama VpnService, non intercetta pacchetti e non compete per quello slot. Associa una porta e accetta connessioni, che è la stessa cosa che farebbe senza alcun VPN installato. Il mito quindi confonde un limite sui fornitori di tunnel con un limite sulle connessioni di rete, e i due non hanno alcun rapporto.

Il listener è una destinazione, non parte del tunnel

Una volta che il tunnel esiste, il telefono ha un indirizzo su di esso e il dispositivo peer ha una rotta verso quell'indirizzo. Se qualcosa risponde lo decide il listener. Un demone associato al loopback è raggiungibile solo dal telefono stesso; un demone associato al vecchio indirizzo del tunnel può mantenere il suo binding dopo una riconnessione mentre l'indirizzo a cui si è associato è cambiato.

Le regole di binding sono configurazione SSH ordinaria: l'indirizzo e la porta di ascolto, e chi può autenticarsi. Su Android queste impostazioni risiedono nella configurazione dell'app stessa, e il proprietario del processo dell'app potrebbe non avere il permesso di usare porte privilegiate, quindi l'abitudine desktop di associare la porta 22 come root non si trasferisce invariata.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Poi c'è il permesso sul percorso stesso. Un VPN consumer che trasporta volentieri il traffico web in uscita non deve affatto consentire connessioni in entrata verso i suoi clienti; molti non lo fanno, perché esporrebbe un cliente a un altro. Se il peer non riesce a raggiungere l'indirizzo del tunnel del telefono da nessuna parte, il problema sta nella politica del servizio e non nel telefono.

Il percorso di ritorno è dove di solito si rompe

Supponiamo che il peer raggiunga l'indirizzo del tunnel del telefono e che arrivi il SYN. Ora la risposta deve uscire per lo stesso percorso, e questa è una decisione di routing dentro il telefono. Se la risposta esce via Wi-Fi perché quella è la rete predefinita, il peer vede una connessione che non si completa mai, che sembra esattamente un firewall.

Android rende la cosa più complicata di un desktop perché la rete predefinita viene scelta per processo e può essere cambiata dalla politica dell'app VPN. Un client VPN può instradare solo un elenco di applicazioni consentite, quindi un'app server fuori da quell'elenco continua a usare la rete fisica per le sue risposte mentre il peer le aspetta attraverso il tunnel.

Un'app può anche associare i propri socket a una rete specifica, il che sovrascrive il valore predefinito. Quando leggi un rapporto secondo cui un servizio è raggiungibile da un indirizzo e non da un altro, di solito è questo il meccanismo che ci sta dietro.

Aggirare il VPN non ripara un servizio in entrata

La soluzione popolare, escludere l'app SSH dal VPN perché il suo traffico smetta di essere reindirizzato, è una correzione per il problema opposto. Aiuta quando il trasporto di un client SSH in uscita continua a rompersi a causa del tunnel. Per un server ospitato può spostare le risposte fuori dal tunnel che il peer sta usando, il che trasforma un guasto parziale in uno totale.

Lo stesso vale per l'apertura di una porta pubblica sul router. Se il requisito è che un dispositivo autorizzato raggiunga il telefono tramite il VPN, esporre SSH a internet è un modello di minaccia diverso e non una riparazione.

Decidi prima l'indirizzo del servizio: l'indirizzo LAN del telefono, il suo indirizzo di tunnel o un endpoint inoltrato di proposito. Ognuno ha il proprio contratto di raggiungibilità ed esposizione, e mescolarli è il modo in cui un piccolo problema di accesso diventa un buco permanente.

Diagnostica una direzione alla volta

Annota quattro fatti prima di cambiare la configurazione: l'indirizzo a cui si connette il peer, lo stato del listener sul telefono, il contesto di app e utente che lo possiede e il percorso osservato in ciascuna direzione. Un rapporto che dice che il VPN disconnette SSH non ne contiene nessuno e non può distinguere un problema di trasporto del client da un server irraggiungibile.

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

Esegui il controllo della porta dal peer, non dal telefono, e leggi l'output dettagliato del client SSH per vedere se fallisce prima o dopo l'handshake TCP. Un socket che non si connette mai e un login rifiutato sono fasi diverse con responsabili diversi.

Mantieni intatti la verifica della chiave dell'host e le restrizioni dell'account mentre esegui il debug. Limitare il listener e gli utenti consentiti è ciò che rende accettabile un server raggiungibile; allentarli per far funzionare una connessione scambia un problema con uno peggiore. Il riferimento del server OpenSSH copre i controlli di ascolto e accesso se la tua implementazione Android segue gli stessi nomi di configurazione.