Androids regel om én VPN blokerer ikke en SSH-server på telefonen

Overbevisningen er så udbredt, at den behandles som fakta: Android tillader kun én VPN, så en SSH-server på telefonen kan ikke fungere gennem den tunnel. Den første halvdel er sand, og konklusionen følger ikke. Platformens grænse handler om, hvor mange apps der kan holde VPN-tjenestens plads, ikke om hvor mange sockets der kan findes, eller hvem der må forbinde til telefonen. En SSH-dæmon med en lyttende socket er en almindelig app med en almindelig port, og tunnelen er en af de veje, dens trafik kan tage.

Hvad reglen om én VPN egentlig begrænser

VpnService er en ressource med én plads. Når en app etablerer en tunnel, bliver den enhedens VPN, og en anden app, der forsøger, afvises, indtil den første forsvinder. Det er en regel om ejerskab af tunnelen, og den forklarer, hvorfor to VPN-klienter ikke kan køre samtidigt.

Om lyttende sockets siger den intet. SSH-serveren kalder ikke VpnService, opfanger ikke pakker og konkurrerer ikke om den plads. Den binder en port og accepterer forbindelser, hvilket er det samme, den ville gøre uden nogen VPN installeret. Myten forveksler altså en grænse for tunneludbydere med en grænse for netværksforbindelser, og de to har ingen forbindelse.

Lytteren er en destination, ikke en del af tunnelen

Når tunnelen findes, har telefonen en adresse på den, og peer-enheden har en rute til den adresse. Om noget svarer, afgøres af lytteren. En dæmon bundet til loopback kan kun nås fra telefonen selv; en dæmon bundet til tunnellens gamle adresse kan beholde bindingen efter en genopkobling, selv om adressen er ændret.

Bindingsregler er almindelig SSH-konfiguration: lytteadressen og porten, og hvem der må godkendes. På Android ligger disse indstillinger i appens egen konfiguration, og ejeren af appens proces har måske ikke tilladelse til at bruge privilegerede porte, så skrivebordsvanen med at binde port 22 som root overføres ikke uændret.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Så er der tilladelse på selve vejen. En forbruger-VPN, der gerne bærer udgående webtrafik, behøver slet ikke tillade indgående forbindelser til sine kunder; mange gør det ikke, fordi det ville udsætte én kunde for en anden. Hvis peer-en ikke kan nå telefonens tunneladresse nogen steder fra, ligger problemet i tjenestens politik og ikke i telefonen.

Svarvejen er hvor det som regel bryder sammen

Antag at peer-en når telefonens tunneladresse, og at SYN ankommer. Nu skal svaret forlade samme vej, og det er en routingbeslutning inde i telefonen. Hvis svaret går ud over Wi-Fi, fordi det er standardnetværket, ser peer-en en forbindelse, der aldrig fuldføres, og det ligner præcis en firewall.

Android gør dette mere kompliceret end en computer, fordi standardnetværket vælges pr. proces og kan ændres af VPN-appens politik. En VPN-klient kan kun route en liste af tilladte apps, så en serverapp uden for den liste fortsætter med at bruge det fysiske netværk til sine svar, mens peer-en forventer dem gennem tunnelen.

En app kan også binde sine egne sockets til et bestemt netværk, hvilket tilsidesætter standarden. Når du læser en rapport om, at en tjeneste kan nås fra én adresse og ikke fra en anden, er det som regel den mekanisme, der ligger bag.

At omgå VPN reparerer ikke en indgående tjeneste

Den populære løsning, at udelukke SSH-appen fra VPN, så dens trafik ikke længere omdirigeres, er en reparation af det modsatte problem. Den hjælper, når en udgående SSH-klients transport hele tiden bryder sammen på grund af tunnelen. For en hostet server kan den flytte svarene ud af den tunnel, peer-en bruger, og det gør en delvis fejl til en total.

Det samme gælder for at åbne en offentlig port på routeren. Hvis kravet er, at én autoriseret enhed når telefonen over VPN, er det at eksponere SSH mod internettet en anden trusselsmodel og ikke en reparation.

Beslut først tjenestens adresse: telefonens LAN-adresse, dens tunneladresse eller et bevidst videresendt endepunkt. Hver har sin egen kontrakt for tilgængelighed og eksponering, og at blande dem er måden, hvorpå et lille adgangsproblem bliver et permanent hul.

Diagnostiser én retning ad gangen

Skriv fire fakta ned, før du ændrer konfigurationen: adressen peer-en forbinder til, lytterens tilstand på telefonen, den app- og brugerkontekst, der ejer den, og den vej, der ses i hver retning. En rapport om, at VPN afbryder SSH, indeholder ikke én af dem og kan ikke skelne et transportproblem hos klienten fra en utilgængelig server.

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

Kør porttjekket fra peer-en, ikke fra telefonen, og læs SSH-klientens detaljerede output for at se, om det fejler før eller efter TCP-håndtrykket. En socket, der aldrig forbinder, og et afvist login er forskellige faser med forskellige ejere.

Bevar værtsnøgleverifikation og kontobegrænsninger, mens du fejlfinder. Det er begrænsningen af lytteren og de tilladte brugere, der gør en tilgængelig server acceptabel; at lempe dem for at få en forbindelse til at virke bytter et problem for et værre. OpenSSH-serverreferencen dækker lytte- og adgangskontrollerne, hvis din Android-implementering følger de samme konfigurationsnavne.