Android SSH SOCKS-proxy: Derfor er det kun halvdelen af dine apper, der forbinder

Du logger ind over SSH, tilføjer -D 1080, og kommandoen lykkes. En SOCKS-lytter findes nu på telefonen, og halvdelen af apperne går stadig ud over mobildata. Det er det normale resultat, ikke en ødelagt tunnel: ssh -D opretter et proxy-endepunkt, og Android-applikationer bruger kun en proxy, hvis noget får dem til det. At gå kæden igennem trin for trin viser, hvor hver del af opgaven faktisk ligger.

Start der, hvor trafikken starter

Vælg en app, der bør bruge tunnelen, og undersøg, om den har sin egen proxyindstilling. En browser med et SOCKS-felt er det nemme tilfælde: peg den mod 127.0.0.1:1080, slå fjern-DNS til, hvis indstillingen findes, og anmodningen går igennem. En chatklient, en kortapp eller et spil uden et sådant felt har ingen måde at bruge lytteren på, og intet, du skriver i SSH-kommandoen, ændrer det.

Før du inddrager noget andet, skal du bevise, at lytteren virker fra telefonens eget shell med en klient, der taler SOCKS direkte:

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

Den adresse, der kommer tilbage, skal være SSH-serverens, ikke telefonens. Er den det, er proxy-halvdelen færdig, og resten af arbejdet handler om dækning. Er den ikke, skal du først rette SSH-siden: nøgleautentificering, serverens evne til at nå destinationen og SSH-serverens egen udgang.

Tilføj den del, Android har brug for

Applikationer uden en proxyindstilling har brug for noget, der fanger deres pakker og gør dem til proxyforbindelser. På en enhed uden root er det en VPN-serviceadapter: en app, der tager det virtuelle interface og videresender udvalgt trafik til den lokale SOCKS-lytter. Kæden bliver app, adapter, SOCKS-lytter, SSH-forbindelse, destination.

Installér adapteren, giv den VPN-tilladelse, og vælg de apper eller ruter, den skal fange. Nøgleikonet i statuslinjen repræsenterer derefter adapteren, ikke en separat kommerciel VPN. Android tillader kun én aktiv VPN-serviceforbindelse pr. brugerprofil, så en anden VPN-app lægger ikke et lag oven på kæden; den konkurrerer om den samme rolle.

Det er også her, en vellykket test kan vildlede dig. Hvis adapteren kun fanger den browser, du allerede pegede mod proxyen, virker alt, og intet andet er dækket. Læs fangstlisten, før du konkluderer, at enheden er tunneleret.

Hold SSH-transporten uden for fangsten

Selve SSH-forbindelsen må ikke føres tilbage i den SOCKS-tunnel, den vedligeholder. Hvis adapteren fanger SSH-appens trafik, afhænger tunnelen af en forbindelse, der venter på tunnelen, og resultatet er en løkke, der går i stå eller fejler, så snart adapteren starter.

Integrerede implementeringer beskytter deres egen transportsocket. Med separate apper har du brug for en understøttet undtagelse: hold SSH-appen uden for fangsten, eller undtag SSH-endepunktet via adresse. Begge dele har omkostninger. Undtager du en hel terminalapp, fjerner du også dens urelaterede netværksaktivitet fra tunnelen, og en adresseundtagelse bryder sammen, når serverens adresse ændres, eller når navnet opløses anderledes ved næste forbindelse.

Kontrollér undtagelsen udefra: genopret adapteren, og bekræft derefter, at SSH-sessionen overlever, og at den proxede anmodning stadig rapporterer serverens adresse. En session, der virker indtil adapteren starter og derefter fryser, er løkken.

Følg DNS og UDP til kædens ende

OpenSSHs dynamiske forward bærer TCP-forbindelser. Det er ikke en UDP-associate- eller ICMP-transport, og en adapter kan ikke opfinde UDP-videresendelse ved at acceptere UDP-pakker. Alt, der insisterer på UDP, inklusive QUIC og WebRTC-medier, vil enten fejle eller falde tilbage til TCP afhængigt af appen.

DNS kræver sin egen beslutning. En app, der opløser et navn lokalt, sender forespørgslen gennem den normale resolver, før den forbinder, så tunnelen bærer forbindelsen, men ikke opslaget. En proxybevidst klient med en fjern-DNS-indstilling undgår det; en fanget app uden en gør ikke. Kontrollér, hvilken resolver der svarede, i stedet for at antage, at adapteren ændrede det.

Hold SOCKS-lytteren bundet til loopback, verificér SSH-serverens host key ved første brug, og lad normal HTTPS-validering være på plads for det endelige websted. SSH beskytter telefon-til-server-segmentet; det krypterer ikke det, serveren gør bagefter.

Kontrollér de to levetider, og beslut

Adapteren og SSH-sessionen har separate levetider. Falder SSH, mens adapteren fortsætter med at fange, kan apper hænge uden nogen tydelig fejl, fordi deres pakker stadig kommer ind i et virtuelt interface, der ikke længere har en fungerende udgang. Stopper adapteren, går apperne enten direkte eller blokeres, afhængigt af enhedens VPN-politik.

Test begge retninger med vilje: dræb SSH-sessionen med adapteren kørende, og stop derefter adapteren, mens SSH bliver oppe. Det, telefonen gør i hvert tilfælde, er den politik, du reelt udruller, uanset hvad opsætningsvejledningen påstod.

Hvis arbejdsgangen kræver dækning for hele enheden med en forudsigelig fejltilstand, er en rigtig IP-VPN, eller en vedligeholdt adapter designet til denne kæde, det ærlige svar. En shell-session, der kører ved siden af en urelateret fangstapp, er ikke en vedligeholdt enhedstunnel; det er to komponenter uden en aftale om, hvad der sker, når en af dem slutter.