Androids regel med bare én VPN stenger ikke ute en hostet SSH-tjener

Oppfatningen er utbredt nok til at den behandles som en kjensgjerning: Android gir bare plass til én VPN, og dermed skulle en SSH-tjener på telefonen ikke kunne virke over den tunnelen. Første del stemmer, men konklusjonen holder ikke. Plattformbegrensningen dreier seg om hvor mange apper som kan holde plassen som VPN-tjeneste, ikke om hvor mange sockets som kan finnes, eller hvem som har lov til å koble seg til telefonen. En SSH-demon som lytter på en socket, er en helt vanlig app med en helt vanlig port, og tunnelen er bare én av veiene trafikken kan ta.

Hva regelen om én VPN egentlig begrenser

VpnService er en ressurs med én plass. Når en app setter opp en tunnel, blir den enhetens VPN, og en annen app som forsøker det samme, blir avvist helt til den første er borte. Dette er en regel om eierskap til tunnelen, og den forklarer hvorfor to VPN-klienter ikke kan kjøre samtidig.

Om lyttende sockets sies det ingenting. SSH-tjeneren kaller ikke VpnService, fanger ikke opp pakker og konkurrerer ikke om den plassen. Den binder en port og tar imot tilkoblinger, akkurat slik den ville gjort uten VPN installert i det hele tatt. Myten blander altså en grense for tunnelleverandører sammen med en grense for nettverkstilkoblinger, og de to henger ikke sammen.

Lytteren er et mål, ikke en del av tunnelen

Når tunnelen er der, har telefonen en adresse på den, og partnereinheten har en rute dit. Om noe svarer, avgjøres av lytteren. En demon som er bundet til loopback, er bare tilgjengelig fra telefonen selv; en demon bundet til den gamle tunneladressen kan beholde bindingen etter en ny tilkobling, selv om adressen den bandt seg til er endret.

Bindingsreglene er helt vanlig SSH-oppsett: lytteadresse og port, og hvem som får autentisere seg. På Android ligger disse innstillingene i appens egen konfigurasjon, og eieren av appprosessen har kanskje ikke tillatelse til å bruke privilegerte porter, så vanen fra skrivebordet med å binde port 22 som root overføres ikke uten videre.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Så kommer tillatelsen på selve veien. En forbruker-VPN som gladelig frakter utgående webtrafikk, behøver ikke å tillate innkommende tilkoblinger til kundene sine i det hele tatt; mange lar være, fordi det ville utlevere én kunde til en annen. Hvis partneren ikke kommer seg til telefonens tunneladresse fra noe sted, ligger problemet i tjenestens policy og ikke i telefonen.

Returveien er der det vanligvis ryker

Tenk deg at partneren når telefonens tunneladresse og at SYN-pakken kommer inn. Nå må svaret ut samme vei, og det er en ruteavgjørelse inne i telefonen. Går svaret ut over Wi-Fi fordi det er standardnettverket, ser partneren en tilkobling som aldri fullføres, og det ser nøyaktig ut som en brannmur.

Android gjør dette vanskeligere enn på en skrivebordsmaskin, fordi standardnettverket velges per prosess og kan endres av policyen til VPN-appen. En VPN-klient kan bare rute en liste over tillatte apper, så en serverapp utenfor listen fortsetter å bruke det fysiske nettverket til svarene sine mens partneren venter på dem gjennom tunnelen.

En app kan også binde sine egne sockets til et bestemt nettverk, og det overstyrer standardvalget. Når du leser en rapport om at en tjeneste er tilgjengelig fra én adresse og ikke fra en annen, er det som regel denne mekanismen som ligger bak.

Å gå utenom VPN reparerer ikke en innkommende tjeneste

Den populære omveien, å utelukke SSH-appen fra VPN slik at trafikken slutter å bli omdirigert, er en retting av det motsatte problemet. Den hjelper når transporten til en utgående SSH-klient stadig bryter sammen på grunn av tunnelen. For en hostet tjener kan den flytte svarene ut av tunnelen partneren bruker, og dermed gjøre en delvis feil til en fullstendig.

Det samme gjelder å åpne en offentlig port på ruteren. Er kravet at én autorisert enhet skal nå telefonen over VPN, er det å eksponere SSH mot internett en annen trusselmodell og ikke en reparasjon.

Bestem tjenesteadressen først: telefonens LAN-adresse, tunneladressen eller et bevisst videresendt endepunkt. Hver av dem har sin egen avtale om tilgjengelighet og eksponering, og å blande dem er måten et lite tilgangsproblem blir et permanent hull.

Diagnostiser én retning om gangen

Skriv ned fire fakta før du endrer konfigurasjonen: adressen partneren kobler til, lytterens tilstand på telefonen, app- og brukerkonteksten som eier den, og veien som er observert i hver retning. En rapport som sier at VPN kobler fra SSH, inneholder ingen av dem og kan ikke skille et transportproblem hos klienten fra en utilgjengelig tjener.

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

Kjør portkontrollen fra partneren, ikke fra telefonen, og les den detaljerte utskriften fra SSH-klienten for å se om den feiler før eller etter TCP-håndtrykket. En socket som aldri kobles til, og en pålogging som avvises, er forskjellige stadier med forskjellige ansvarlige.

La vertsnøkkelverifisering og kontobegrensninger være urørt mens du feilsøker. Det er nettopp begrensningen av lytteren og de tillatte brukerne som gjør en tilgjengelig tjener forsvarlig; å lempe på dem for å få en tilkobling til å virke bytter ett problem mot et verre. Referansen for OpenSSH-tjeneren dekker lytte- og tilgangskontrollene hvis Android-implementasjonen din følger de samme konfigurasjonsnavnene.