De Android-regel voor één VPN blokkeert geen gehoste SSH-server

Het geloof is gangbaar genoeg om als feit te worden behandeld: Android staat maar één VPN toe, dus een SSH-server op de telefoon kan niet via die tunnel werken. De eerste helft klopt en de conclusie volgt er niet uit. De platformlimiet gaat over hoeveel apps de plek van de VPN-dienst mogen innemen, niet over hoeveel sockets er kunnen bestaan of wie verbinding mag maken met de telefoon. Een SSH-daemon met een luisterende socket is een gewone app met een gewone poort, en de tunnel is een van de paden die het verkeer kan nemen.

Wat de regel van één VPN werkelijk beperkt

VpnService is een hulpbron met één plek. Wanneer een app een tunnel opzet, wordt die de VPN van het toestel, en een tweede app die er een probeert op te zetten wordt geweigerd tot de eerste verdwijnt. Dat is een regel over tunnelseigendom, en het verklaart waarom twee VPN-clients niet tegelijk kunnen draaien.

Over luisterende sockets zegt het niets. De SSH-server roept VpnService niet aan, onderschept geen pakketten en dingt niet mee naar die plek. Hij bindt een poort en accepteert verbindingen, precies wat hij zou doen zonder geïnstalleerde VPN. De mythe verwart dus een limiet op tunnelproviders met een limiet op netwerkverbindingen, en die twee hebben niets met elkaar te maken.

De listener is een bestemming, geen deel van de tunnel

Zodra de tunnel bestaat, heeft de telefoon er een adres op en heeft het partnertoestel een route naar dat adres. Of er iets antwoordt, bepaalt de listener. Een daemon die aan loopback is gebonden, is alleen vanaf de telefoon zelf bereikbaar; een daemon die aan het oude tunneladres is gebonden, kan zijn binding na een herverbinding behouden terwijl het adres waaraan hij zich bond is veranderd.

Bindregels zijn gewone SSH-configuratie: het luisteradres en de poort, en wie zich mag authenticeren. Op Android staan die instellingen in de configuratie van de app zelf, en de eigenaar van het app-proces mag misschien geen geprivilegieerde poorten gebruiken, dus de desktopgewoonte om poort 22 als root te binden wordt niet ongewijzigd overgedragen.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Dan is er de toestemming op het pad zelf. Een consumenten-VPN die uitgaand webverkeer graag vervoert, hoeft inkomende verbindingen naar zijn klanten helemaal niet toe te staan; veel doen dat niet, omdat het de ene klant aan de andere zou blootstellen. Als de partner het tunneladres van de telefoon nergens kan bereiken, zit het probleem in het beleid van de dienst en niet in de telefoon.

Het antwoordpad is waar het meestal breekt

Stel dat de partner het tunneladres van de telefoon bereikt en de SYN binnenkomt. Nu moet het antwoord via hetzelfde pad naar buiten, en dat is een routeringsbeslissing binnen de telefoon. Als het antwoord via Wi-Fi naar buiten gaat omdat dat het standaardnetwerk is, ziet de partner een verbinding die nooit voltooid wordt, wat er precies als een firewall uitziet.

Android maakt dit ingewikkelder dan een desktop omdat het standaardnetwerk per proces wordt gekozen en door het beleid van de VPN-app kan worden gewijzigd. Een VPN-client kan alleen een lijst met toegestane apps routeren, dus een serverapp buiten die lijst blijft het fysieke netwerk gebruiken voor zijn antwoorden terwijl de partner ze via de tunnel verwacht.

Een app kan zijn eigen sockets ook aan een specifiek netwerk binden, wat de standaard overschrijft. Als je een rapport leest dat een dienst vanaf het ene adres bereikbaar is en vanaf het andere niet, is dit meestal het mechanisme erachter.

De VPN omzeilen herstelt geen inkomende dienst

De populaire omweg, de SSH-app van de VPN uitsluiten zodat het verkeer niet meer wordt omgeleid, is een oplossing voor het tegenovergestelde probleem. Het helpt wanneer het transport van een uitgaande SSH-client steeds breekt door de tunnel. Voor een gehoste server kan het de antwoorden buiten de tunnel brengen die de partner gebruikt, waardoor een gedeeltelijke storing een totale wordt.

Hetzelfde geldt voor het openen van een openbare poort op de router. Als de eis is dat één geautoriseerd toestel de telefoon via de VPN bereikt, is SSH aan het internet blootstellen een ander dreigingsmodel en geen reparatie.

Bepaal eerst het adres van de dienst: het LAN-adres van de telefoon, het tunneladres of een bewust doorgestuurd eindpunt. Elk heeft zijn eigen contract voor bereikbaarheid en blootstelling, en ze door elkaar halen is hoe een klein toegangsprobleem een permanent gat wordt.

Diagnostiseer één richting tegelijk

Schrijf vier feiten op voordat je de configuratie wijzigt: het adres waarmee de partner verbindt, de toestand van de listener op de telefoon, de app- en gebruikerscontext die hem bezit, en het pad dat in elke richting is waargenomen. Een rapport dat zegt dat de VPN SSH verbreekt bevat er geen enkele van en kan een transportprobleem van de client niet onderscheiden van een onbereikbare server.

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

Voer de poortcontrole uit vanaf de partner, niet vanaf de telefoon, en lees de uitvoer met details van de SSH-client om te zien of hij vóór of ná de TCP-handshake faalt. Een socket die nooit verbindt en een geweigerde login zijn verschillende fasen met verschillende verantwoordelijken.

Houd de verificatie van de hostsleutel en de accountbeperkingen intact terwijl je debugt. Het beperken van de listener en de toegestane gebruikers is wat een bereikbare server aanvaardbaar maakt; ze versoepelen om een verbinding werkend te krijgen ruilt één probleem voor een erger. De OpenSSH-serverreferentie behandelt de luister- en toegangscontroles als je Android-implementatie dezelfde configuratienamen volgt.