Android SSH SOCKS-proxy: derfor kobler bare halvparten av appene dine til

Du logger på over SSH, legger til -D 1080, og kommandoen lykkes. Nå finnes det en SOCKS-lytter på telefonen, og halvparten av appene går fortsatt ut over mobildata. Det er det normale resultatet, ikke en ødelagt tunnel: ssh -D lager et proxy-endepunkt, og Android-apper bruker bare proxy hvis noe tvinger dem. Å gå gjennom kjeden trinn for trinn viser hvor hver del av jobben faktisk bor.

Start der trafikken starter

Velg én app som skal bruke tunnelen, og sjekk om den har sin egen proxy-innstilling. En nettleser med SOCKS-felt er det enkle tilfellet: pek den mot 127.0.0.1:1080, slå på ekstern DNS hvis innstillingen finnes, og forespørselen går gjennom. En chatklient, en kartapp eller et spill uten et slikt felt har ingen måte å bruke lytteren på, og ingenting du skriver i SSH-kommandoen endrer det.

Før du involverer noe annet, bevis at lytteren virker fra telefonens egen shell med en klient som snakker SOCKS direkte:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

Adressen som kommer tilbake skal være SSH-serverens, ikke telefonens. Er den det, er proxy-halvdelen ferdig, og resten av arbeidet handler om dekning. Er den ikke det, fiks SSH-siden først: nøkkelautentisering, serverens evne til å nå målet, og SSH-serverens egen utgang.

Legg til delen Android trenger

Apper uten proxy-innstilling trenger noe som fanger pakkene deres og gjør dem om til proxy-forbindelser. På en enhet uten root er det en VPN-tjenesteadapter: en app som tar det virtuelle grensesnittet og videresender valgt trafikk til den lokale SOCKS-lytteren. Kjeden blir app, adapter, SOCKS-lytter, SSH-forbindelse, mål.

Installer adapteren, gi den VPN-tillatelse og velg appene eller rutene den skal fange. Nøkkelikonet i statuslinjen representerer da adapteren, ikke en separat kommersiell VPN. Android tillater én aktiv VPN-tjenesteforbindelse per brukerprofil, så å starte en andre VPN-app legger ikke et lag på kjeden: den konkurrerer om samme rolle.

Dette er også trinnet der en vellykket test kan lure deg. Hvis adapteren er satt til å fange bare nettleseren du allerede pekte mot proxyen, virker alt og ingenting annet er dekket. Les fangstlisten før du konkluderer med at enheten er tunnelert.

Hold SSH-transporten utenfor fangsten

Selve SSH-forbindelsen må ikke føres tilbake i SOCKS-tunnelen den opprettholder. Hvis adapteren fanger trafikken til SSH-appen, avhenger tunnelen av en forbindelse som venter på tunnelen, og resultatet er en løkke som stopper eller feiler så snart adapteren starter.

Integrerte implementasjoner beskytter sin egen transport-socket. Med separate apper trenger du et støttet unntak: hold SSH-appen utenfor fangsten, eller unnta SSH-endepunktet etter adresse. Begge har en kostnad. Å unnta en hel terminalapp fjerner også dens urelaterte nettverksaktivitet fra tunnelen, og et adresseunntak bryter sammen når serveradressen endres eller når navnet løses annerledes ved neste tilkobling.

Sjekk unntaket fra utsiden: koble adapteren til på nytt, og bekreft deretter at SSH-økten overlever og at den proxyede forespørselen fortsatt rapporterer serveradressen. En økt som virker til adapteren starter og deretter fryser, er den løkka.

Følg DNS og UDP til enden av kjeden

OpenSSHs dynamiske videresending bærer TCP-forbindelser. Det er ikke en UDP-associate- eller ICMP-transport, og en adapter kan ikke finne opp UDP-videresending ved å ta imot UDP-pakker. Alt som insisterer på UDP, inkludert QUIC og WebRTC-media, vil enten feile eller falle tilbake til TCP avhengig av appen.

DNS trenger sin egen beslutning. En app som løser et navn lokalt, sender spørringen gjennom den vanlige resolveren før den kobler til, så tunnelen bærer forbindelsen men ikke oppslaget. En proxybevisst klient med ekstern DNS-mulighet unngår det; en fanget app uten den gjør det ikke. Sjekk hvilken resolver som svarte i stedet for å anta at adapteren endret det.

Hold SOCKS-lytteren bundet til loopback, verifiser host-nøkkelen til SSH-serveren ved første bruk, og la vanlig HTTPS-validering stå på plass for sluttstedet. SSH beskytter strekningen telefon-til-server; det krypterer ikke det serveren gjør etterpå.

Sjekk de to levetidene og bestem

Adapteren og SSH-økten har separate levetider. Hvis SSH faller mens adapteren fortsetter å fange, kan apper henge uten åpenbar feil, fordi pakkene deres fortsatt går inn i et virtuelt grensesnitt som ikke lenger har en fungerende utgang. Hvis adapteren stopper, går appene enten direkte eller blir blokkert, avhengig av enhetens VPN-policy.

Test begge retninger med vilje: drep SSH-økten mens adapteren kjører, og stopp deretter adapteren mens SSH blir stående. Det telefonen gjør i hvert tilfelle er policyen du faktisk ruller ut, uansett hva installasjonsinstruksjonene hevdet.

Hvis arbeidsflyten trenger dekning for hele enheten med en forutsigbar feilmodus, er en ekte IP VPN, eller en vedlikeholdt adapter laget for denne kjeden, det ærlige svaret. En shell-økt som får stå og gå ved siden av en urelatert fangeapp er ikke en vedlikeholdt enhetstunnel; det er to komponenter uten avtale om hva som skjer når en av dem avsluttes.