Androids regel om én VPN blokkerer ikke en hostet SSH-tjener

Troen er vanlig nok til å bli behandlet som et faktum: Android tillater bare én VPN, så en SSH-tjener som kjører på telefonen kan ikke fungere gjennom den tunnelen. Den første halvdelen er sann, og konklusjonen følger ikke. Plattformgrensen handler om hvor mange apper som kan holde VPN-tjenestens plass, ikke om hvor mange sockets som kan eksistere eller hvem som har lov til å koble til telefonen. En SSH-demon med en lyttende socket er en vanlig app med en vanlig port, og tunnelen er en av veiene trafikken dens kan ta.

Hva regelen om én VPN faktisk begrenser

VpnService er en ressurs med én plass. Når en app etablerer en tunnel, blir den enhetens VPN, og en andre app som prøver å etablere en, avvises til den første forsvinner. Det er en regel om tunneleierskap, og den forklarer hvorfor to VPN-klienter ikke kan kjøre samtidig.

Den sier ingenting om lyttende sockets. SSH-tjeneren kaller ikke VpnService, fanger ikke opp pakker og konkurrerer ikke om den plassen. Den binder en port og tar imot tilkoblinger, det samme den ville gjort uten noen VPN installert. Så myten blander en grense for tunnelleverandører med en grense for nettverkstilkoblinger, og de to har ingen sammenheng.

Lytteren er en destinasjon, ikke en del av tunnelen

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

Bindingsreglene er vanlig SSH-konfigurasjon: lytteadressen og porten, og hvem som kan autentisere seg. På Android ligger disse innstillingene i appens egen konfigurasjon, og eieren av appprosessen har kanskje ikke lov til å bruke privilegerte porter, så skrivebordsvanen med å binde port 22 som root overføres ikke uendret.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Så er det tillatelsen på selve veien. En forbruker-VPN som gjerne bærer utgående webtrafikk trenger ikke å tillate innkommende tilkoblinger til klientene sine i det hele tatt; mange gjør det ikke, fordi det ville eksponere én kunde for en annen. Hvis partneren ikke kan nå telefonens tunneladresse fra noe sted, ligger problemet i tjenestens policy og ikke i telefonen.

Svarveien er der det vanligvis bryter sammen

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

Android gjør dette mer komplisert enn en skrivebordsmaskin fordi standardnettverket velges per prosess og kan endres av VPN-appens policy. En VPN-klient kan bare rute en liste over tillatte apper, så en serverapp utenfor den 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, noe som overstyrer standarden. Når du leser en rapport om at en tjeneste er tilgjengelig fra én adresse og ikke fra en annen, er dette vanligvis mekanismen bak.

Å omgå VPN reparerer ikke en innkommende tjeneste

Den populære omveien, å utelukke SSH-appen fra VPN slik at trafikken slutter å bli omdirigert, er en rettelse for 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, noe som gjør en delvis feil til en total.

Det samme gjelder å åpne en offentlig port på ruteren. Hvis kravet er at én autorisert enhet når 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 kontrakt for tilgjengelighet og eksponering, og å blande dem er hvordan 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 utdataen fra SSH-klienten for å se om den feiler før eller etter TCP-håndtrykket. En socket som aldri kobles til og en avvist innlogging er forskjellige stadier med forskjellige ansvarlige.

Hold vertsnøkkelverifisering og kontobegrensninger intakte mens du feilsøker. Det er begrensningen av lytteren og de tillatte brukerne som gjør en tilgjengelig tjener akseptabel; å lempe på dem for å få en tilkobling til å virke bytter ett problem mot et verre. OpenSSH-tjenerreferansen dekker lytte- og tilgangskontrollene hvis Android-implementasjonen din følger de samme konfigurasjonsnavnene.