Android SSH SOCKS proxy: miért csak az alkalmazásaid fele csatlakozik

SSH-n bejelentkezel, hozzáadod a -D 1080 kapcsolót, és a parancs sikerül. Most van egy SOCKS-figyelő a telefonon, és az alkalmazások fele mégis mobiladatról megy ki. Ez a normális eredmény, nem törött alagút: a ssh -D proxyvégpontot hoz létre, és az Android-alkalmazások csak akkor használnak proxyt, ha valami rákényszeríti őket. A lánc lépésenkénti végigjárása megmutatja, hol él valójában a munka egyes darabja.

Ott kezdd, ahol a forgalom kezdődik

Válassz egy alkalmazást, amelynek az alagutat kellene használnia, és nézd meg, van-e saját proxybeállítása. A SOCKS-mezővel rendelkező böngésző az egyszerű eset: irányítsd a 127.0.0.1:1080 címre, kapcsold be a távoli DNS-t, ha létezik a beállítás, és a kérés átmegy. Egy csevegőprogramnak, térképalkalmazásnak vagy játéknak ilyen mező nélkül nincs módja használni a figyelőt, és azon semmi nem változtat, amit az SSH-parancsba írsz.

Mielőtt bármi mást bevonnal, bizonyítsd, hogy a figyelő a telefon saját shelljéből működik egy SOCKS-t közvetlenül beszélő klienssel:

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

A visszakapott cím az SSH-kiszolgálóé kell legyen, nem a telefoné. Ha az, a proxy fele kész, a többi munka a lefedettségről szól. Ha nem, előbb az SSH-oldalt javítsd: kulcsos hitelesítés, a kiszolgáló képessége a cél elérésére, és az SSH-kiszolgáló saját kimenete.

Add hozzá azt a darabot, amire az Androidnak szüksége van

A proxybeállítás nélküli alkalmazásoknak kell valami, ami elkapja a csomagjaikat és proxykapcsolatokká alakítja. Root nélküli eszközön ez egy VPN-szolgáltató adapter: olyan alkalmazás, amely átveszi a virtuális interfészt, és a kiválasztott forgalmat a helyi SOCKS-figyelőhöz továbbítja. A lánc így alakul: alkalmazás, adapter, SOCKS-figyelő, SSH-kapcsolat, cél.

Telepítsd az adaptert, adj neki VPN-engedélyt, és válaszd ki azokat az alkalmazásokat vagy útvonalakat, amelyeket el kell kapnia. Az állapotsor kulcsikona ekkor az adaptert jelöli, nem egy külön kereskedelmi VPN-t. Az Android felhasználói profilonként egy aktív VPN-szolgáltató kapcsolatot engedélyez, ezért egy második VPN-alkalmazás indítása nem tesz réteget a láncra: ugyanazért a szerepért versenyez.

Ez az a lépés is, ahol egy sikeres teszt félrevezethet. Ha az adapter csak azt a böngészőt kapja el, amelyet már a proxyra irányítottál, minden működik, és semmi más nincs lefedve. Olvasd el az elfogási listát, mielőtt arra jutsz, hogy az eszköz alagútban van.

Tartsd az SSH-transzportot az elfogáson kívül

Magát az SSH-kapcsolatot nem szabad visszatáplálni abba a SOCKS-alagútba, amelyet fenntart. Ha az adapter elkapja az SSH-alkalmazás forgalmát, az alagút egy olyan kapcsolattól függ, amely az alagútra vár, és az eredmény egy hurok, amely beragad vagy meghiúsul, amint az adapter elindul.

Az integrált megvalósítások védik a saját transzportsocketüket. Külön alkalmazásokkal támogatott kivétel kell: hagyd az SSH-alkalmazást az elfogáson kívül, vagy zárd ki az SSH-végpontot cím alapján. Mindkettőnek ára van. Egy egész terminálalkalmazás kizárása a nem kapcsolódó hálózati tevékenységét is kiveszi az alagútból, a címkivétel pedig elromlik, amikor a kiszolgáló címe megváltozik, vagy amikor a név a következő kapcsolatnál másképp oldódik fel.

Kívülről ellenőrizd a kivételt: csatlakoztasd újra az adaptert, majd igazold, hogy az SSH-munkamenet túlél, és a proxyzott kérés továbbra is a kiszolgáló címét jelenti. Az a munkamenet, amely az adapter indulásáig működik, majd lefagy, az a hurok.

Kövesd a DNS-t és az UDP-t a lánc végéig

Az OpenSSH dinamikus továbbítása TCP-kapcsolatokat visz. Ez nem UDP-associate vagy ICMP transzport, és egy adapter nem tud UDP-továbbítást kitalálni azzal, hogy UDP-csomagokat fogad. Minden, ami UDP-t követel, beleértve a QUIC-et és a WebRTC-médiát, vagy meghiúsul, vagy visszaesik TCP-re, az alkalmazástól függően.

A DNS-nek saját döntés kell. Az az alkalmazás, amely helyben old fel egy nevet, a lekérdezést a szokásos feloldón keresztül küldi el, mielőtt csatlakozna, így az alagút a kapcsolatot viszi, de a keresést nem. A proxytudatos kliens távoli DNS-opcióval elkerüli ezt; az elfogott alkalmazás ilyen opció nélkül nem. Ellenőrizd, melyik feloldó válaszolt, ahelyett hogy feltételeznéd, hogy az adapter megváltoztatta.

Tartsd a SOCKS-figyelőt a loopbackhez kötve, első használatkor ellenőrizd az SSH-kiszolgáló host kulcsát, és hagyd a szokásos HTTPS-ellenőrzést a helyén a végső oldalnál. Az SSH a telefon és a kiszolgáló közötti szakaszt védi; nem titkosítja azt, amit a kiszolgáló utána tesz.

Ellenőrizd a két életciklust, és dönts

Az adapternek és az SSH-munkamenetnek külön életciklusa van. Ha az SSH elesik, miközben az adapter továbbra is elfog, az alkalmazások látható hiba nélkül megakadhatnak, mert a csomagjaik még mindig egy olyan virtuális interfészbe lépnek, amelynek nincs többé működő kijárata. Ha az adapter leáll, az alkalmazások vagy közvetlenül mennek, vagy blokkolódnak, az eszköz VPN-szabályzatától függően.

Szándékosan teszteld mindkét irányt: öld meg az SSH-munkamenetet az adapter futása közben, majd állítsd le az adaptert, miközben az SSH állva marad. Amit a telefon az egyes esetekben tesz, az a szabályzat, amelyet valóban telepítesz, bármit is állítottak a telepítési útmutatók.

Ha a munkafolyamatnak kiszámítható hibaállapotú, teljes eszközlefedettségre van szüksége, őszinte válasz egy valódi IP VPN vagy egy erre a láncra tervezett, karbantartott adapter. Egy nem kapcsolódó elfogó alkalmazás mellett futni hagyott shell-munkamenet nem karbantartott eszközszintű alagút; az két komponens, amelyek között nincs megállapodás arról, mi történik, amikor az egyik véget ér.