Androidin SSH SOCKS -proxy: miksi vain puolet sovelluksistasi yhdistää

Kirjaudut sisään SSH:lla, lisäät -D 1080 ja komento onnistuu. Puhelimessa on nyt SOCKS-kuuntelija, ja puolet sovelluksista kulkee silti mobiilidatan kautta. Se on normaali tulos, ei rikkinäinen tunneli: ssh -D luo proxy-päätepisteen, ja Android-sovellukset käyttävät proxyä vain, jos jokin pakottaa ne siihen. Ketjun askel askeleelta läpikäyminen näyttää, missä kukin työn osa todella sijaitsee.

Aloita siitä, mistä liikenne alkaa

Valitse yksi sovellus, jonka pitäisi käyttää tunnelia, ja tarkista, onko sillä oma proxy-asetus. Selain, jossa on SOCKS-kenttä, on helppo tapaus: osoita se kohtaan 127.0.0.1:1080, ota etä-DNS käyttöön jos asetus on olemassa, ja pyyntö menee läpi. Chat-asiakkaalla, karttasovelluksella tai pelillä ilman sellaista kenttää ei ole mitään tapaa käyttää kuuntelijaa, eikä mikään SSH-komentoon kirjoittamasi muuta sitä.

Ennen kuin sotket mitään muuta, todista, että kuuntelija toimii puhelimen omasta komentotulkista asiakkaalla, joka puhuu SOCKSia suoraan:

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

Palautuvan osoitteen pitäisi olla SSH-palvelimen, ei puhelimen. Jos on, proxy-puolisko on valmis ja loput työstä koskee kattavuutta. Jos ei, korjaa ensin SSH-puoli: avaintodennus, palvelimen kyky tavoittaa kohde ja SSH-palvelimen oma ulospääsy.

Lisää se osa, jonka Android tarvitsee

Sovellukset ilman proxy-asetusta tarvitsevat jotain, joka kaappaa niiden paketit ja muuttaa ne proxy-yhteyksiksi. Roottaamattomassa laitteessa se on VPN-palvelusovitin: sovellus, joka ottaa virtuaalisen rajapinnan ja välittää valitun liikenteen paikalliseen SOCKS-kuuntelijaan. Ketjusta tulee sovellus, sovitin, SOCKS-kuuntelija, SSH-yhteys, kohde.

Asenna sovitin, myönnä sille VPN-lupa ja valitse sovellukset tai reitit, jotka sen pitää kaapata. Tilarivin avainkuvake edustaa silloin sovitinta, ei erillistä kaupallista VPN:ää. Android sallii yhden aktiivisen VPN-palveluyhteyden käyttäjäprofiilia kohden, joten toisen VPN-sovelluksen käynnistäminen ei lisää kerrosta ketjuun: se kilpailee samasta roolista.

Tässä vaiheessa onnistunut testi voi myös johtaa harhaan. Jos sovitin on määritetty kaappaamaan vain selain, jonka jo osoitit proxyyn, kaikki toimii eikä mitään muuta ole katettu. Lue kaappauslista ennen kuin päättelet laitteen olevan tunnelissa.

Pidä SSH-siirtoyhteys kaappauksen ulkopuolella

Itse SSH-yhteyttä ei saa syöttää takaisin SOCKS-tunneliin, jota se ylläpitää. Jos sovitin kaappaa SSH-sovelluksen liikenteen, tunneli riippuu yhteydestä, joka odottaa tunnelia, ja tuloksena on silmukka, joka juuttuu tai epäonnistuu heti kun sovitin käynnistyy.

Integroidut toteutukset suojaavat oman siirtoyhteytensä pistokkeen. Erillisillä sovelluksilla tarvitset tuetun poikkeuksen: jätä SSH-sovellus kaappauksen ulkopuolelle tai jätä SSH-päätepiste pois osoitteen perusteella. Molemmilla on hintansa. Koko päätesovelluksen poissulkeminen poistaa tunnelista myös sen muun verkkotoiminnan, ja osoitepoikkeus rikkoutuu, kun palvelimen osoite muuttuu tai kun nimi ratkeaa seuraavalla yhteydellä eri tavoin.

Tarkista poikkeus ulkopuolelta: yhdistä sovitin uudelleen ja varmista sitten, että SSH-istunto säilyy ja että proxyn kautta tehty pyyntö ilmoittaa edelleen palvelimen osoitteen. Istunto, joka toimii kunnes sovitin käynnistyy ja jäätyy sitten, on se silmukka.

Seuraa DNS ja UDP ketjun loppuun

OpenSSH:n dynaaminen edelleenohjaus kuljettaa TCP-yhteyksiä. Se ei ole UDP-associate- eikä ICMP-siirto, eikä sovitin voi keksiä UDP-edelleenohjausta hyväksymällä UDP-paketteja. Kaikki, mikä vaatii UDP:tä, mukaan lukien QUIC ja WebRTC-media, joko epäonnistuu tai putoaa takaisin TCP:hen sovelluksesta riippuen.

DNS tarvitsee oman päätöksensä. Sovellus, joka ratkaisee nimen paikallisesti, lähettää kyselyn tavallisen ratkaisijan kautta ennen yhdistämistä, joten tunneli kuljettaa yhteyden mutta ei hakua. Proxy-tietoinen asiakas, jossa on etä-DNS-vaihtoehto, välttää sen; kaapattu sovellus ilman sitä ei. Tarkista, mikä ratkaisija vastasi, sen sijaan että olettaisit sovittimen muuttaneen sen.

Pidä SOCKS-kuuntelija sidottuna loopbackiin, varmenna SSH-palvelimen host-avain ensimmäisellä käytöllä ja jätä tavallinen HTTPS-vahvistus paikoilleen lopulliselle sivustolle. SSH suojaa puhelimen ja palvelimen välisen osuuden; se ei salaa sitä, mitä palvelin tekee seuraavaksi.

Tarkista kaksi elinkaarta ja päätä

Sovittimella ja SSH-istunnolla on erilliset elinkaaret. Jos SSH katkeaa sovittimen yhä kaapatessa, sovellukset voivat jäädä jumiin ilman näkyvää virhettä, koska niiden paketit tulevat edelleen virtuaaliseen rajapintaan, jolla ei enää ole toimivaa ulospääsyä. Jos sovitin pysähtyy, sovellukset joko menevät suoraan tai estyvät laitteen VPN-käytännöstä riippuen.

Testaa molemmat suunnat tarkoituksella: tapa SSH-istunto sovittimen ollessa käynnissä ja pysäytä sitten sovitin SSH:n pysyessä pystyssä. Se, mitä puhelin kussakin tapauksessa tekee, on käytäntö, jota todella otat käyttöön, riippumatta siitä, mitä asennusohjeet väittivät.

Jos työnkulku vaatii koko laitteen kattavuuden ennustettavalla vikatilalla, todellinen IP VPN tai tälle ketjulle suunniteltu ylläpidetty sovitin on rehellinen vastaus. Vieraan kaappaussovelluksen vieressä käynnissä pidetty komentotulkki-istunto ei ole ylläpidetty laitetunneli; se on kaksi komponenttia, joilla ei ole sopimusta siitä, mitä tapahtuu, kun toinen niistä päättyy.