Androids regel om en enda VPN blockerar inte en hostad SSH-server

Gränsen för en enda VPN begränsar VPN-tjänster, inte sockets. En SSH-server på telefonen misslyckas på grund av lyssnaren, partnerns åtkomst eller returvägen.

Uppfattningen är vanlig nog att behandlas som ett faktum: Android tillåter bara en enda VPN, så en SSH-server som körs på telefonen kan inte fungera genom den tunneln. Den första halvan är sann och slutsatsen följer inte. Plattformsgränsen handlar om hur många appar som kan hålla VPN-tjänstens plats, inte om hur många sockets som kan finnas eller vem som får ansluta till telefonen. En SSH-demon med en lyssnande socket är en vanlig app med en vanlig port, och tunneln är en av de vägar trafiken kan ta.

Vad regeln om en enda VPN faktiskt begränsar

VpnService är en resurs med en enda plats. När en app upprättar en tunnel blir den enhetens VPN, och en andra app som försöker upprätta en nekas tills den första försvinner. Det är en regel om tunnelägande, och den förklarar varför två VPN-klienter inte kan köra samtidigt.

Den säger ingenting om lyssnande sockets. SSH-servern anropar inte VpnService, fångar inte upp paket och konkurrerar inte om den platsen. Den binder en port och tar emot anslutningar, samma sak som den skulle göra utan någon VPN installerad. Myten blandar alltså en gräns för tunnelleverantörer med en gräns för nätverksanslutningar, och de två har ingen koppling.

Lyssnaren är en destination, inte en del av tunneln

När tunneln finns har telefonen en adress på den och partnernheten har en rutt till den adressen. Om något svarar avgörs av lyssnaren. En demon bunden till loopback är bara nåbar från telefonen själv; en demon bunden till den gamla tunneladressen kan behålla sin bindning efter en återanslutning även om adressen den band sig till har ändrats.

Bindningsreglerna är vanlig SSH-konfiguration: lyssningsadressen och porten, och vem som får autentisera sig. På Android ligger dessa inställningar i appens egen konfiguration, och ägaren av appprocessen har kanske inte tillåtelse att använda privilegierade portar, så skrivbordsvanan att binda port 22 som root överförs inte oförändrad.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Sedan kommer tillståndet på själva vägen. En konsument-VPN som gärna bär utgående webbtrafik behöver inte alls tillåta inkommande anslutningar till sina kunder; många gör det inte, eftersom det skulle exponera en kund för en annan. Om partnern inte kan nå telefonens tunneladress varifrån som helst ligger problemet i tjänstens policy och inte i telefonen.

Returvägen är där det brukar brista

Anta att partnern når telefonens tunneladress och att SYN kommer in. Nu måste svaret gå ut samma väg, och det är ett routingbeslut inne i telefonen. Om svaret går ut över Wi-Fi eftersom det är standardnätverket ser partnern en anslutning som aldrig fullbordas, vilket ser precis ut som en brandvägg.

Android gör detta mer komplicerat än en skrivbordsdator eftersom standardnätverket väljs per process och kan ändras av VPN-appens policy. En VPN-klient kan bara routa en lista över tillåtna appar, så en serverapp utanför den listan fortsätter att använda det fysiska nätverket för sina svar medan partnern väntar på dem genom tunneln.

En app kan också binda sina egna sockets till ett visst nätverk, vilket åsidosätter standardvalet. När du läser en rapport om att en tjänst är nåbar från en adress och inte från en annan är det vanligtvis denna mekanism som ligger bakom.

Att kringgå VPN reparerar inte en inkommande tjänst

Den populära omvägen, att undanta SSH-appen från VPN så att dess trafik slutar omdirigeras, är en rättelse för det motsatta problemet. Den hjälper när transporten för en utgående SSH-klient ständigt brister på grund av tunneln. För en hostad server kan den flytta svaren ut ur tunneln som partnern använder, vilket gör ett delvis fel till ett totalt.

Detsamma gäller att öppna en offentlig port i routern. Om kravet är att en auktoriserad enhet når telefonen via VPN, är det att exponera SSH mot internet en annan hotmodell och inte en reparation.

Bestäm tjänstens adress först: telefonens LAN-adress, dess tunneladress eller en medvetet vidarebefordrad slutpunkt. Var och en har sitt eget avtal för nåbarhet och exponering, och att blanda dem är hur ett litet åtkomstproblem blir ett permanent hål.

Diagnostisera en riktning i taget

Skriv ned fyra fakta innan du ändrar konfigurationen: adressen partnern ansluter till, lyssnarens tillstånd på telefonen, app- och användarkontexten som äger den, och vägen som observerats i varje riktning. En rapport som säger att VPN kopplar från SSH innehåller ingen av dem och kan inte skilja ett transportproblem hos klienten från en onåbar server.

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

Kör portkontrollen från partnern, inte från telefonen, och läs SSH-klientens detaljerade utdata för att se om den misslyckas före eller efter TCP-handskakningen. En socket som aldrig ansluter och en avvisad inloggning är olika steg med olika ansvariga.

Håll värdnyckelverifiering och kontobegränsningar intakta medan du felsöker. Det är begränsningen av lyssnaren och de tillåtna användarna som gör en nåbar server acceptabel; att lätta på dem för att få en anslutning att fungera byter ett problem mot ett värre. OpenSSH-serverreferensen täcker lyssnings- och åtkomstkontrollerna om din Android-implementering följer samma konfigurationsnamn.

Relaterade artiklar