Androidi SSH SOCKS-proxy: miks ühendub ainult pool sinu rakendustest

Logid sisse SSH kaudu, lisad -D 1080 ja käsk õnnestub. Telefoni tekib nüüd SOCKS-kuulaja ja pool rakendustest käib ikkagi mobiilse andmeside kaudu välja. See on tavaline tulemus, mitte katkine tunnel: ssh -D loob proxy-lõpp-punkti ja Androidi rakendused kasutavad proxy ainult siis, kui miski sunnib neid. Ahela samm-sammuline läbikäimine näitab, kus iga tööosa tegelikult asub.

Alusta sealt, kust liiklus algab

Vali üks rakendus, mis peaks tunnelit kasutama, ja kontrolli, kas sellel on oma proxy-seade. SOCKS-väljaga brauser on lihtne juhtum: suuna see aadressile 127.0.0.1:1080, luba kaug-DNS, kui seade on olemas, ja päring läheb läbi. Vestlusklient, kaardirakendus või mäng ilma sellise väljata ei saa kuulajat kuidagi kasutada ja miski, mida SSH-käsus kirjutad, seda ei muuda.

Enne kui midagi muud kaasata, tõesta, et kuulaja töötab telefoni enda shellist kliendiga, mis räägib SOCKS-i otse:

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

Tagastatav aadress peaks olema SSH-serveri oma, mitte telefoni oma. Kui on, on proxy pool tehtud ja ülejäänud töö puudutab katvust. Kui ei ole, paranda esmalt SSH pool: võtmeautentimine, serveri võime sihtkohta jõuda ja SSH-serveri enda väljund.

Lisa tükk, mida Android vajab

Rakendused ilma proxy-seadeta vajavad midagi, mis nende paketid kinni püüab ja proxy-ühendusteks muudab. Juureta seadmes on selleks VPN-teenuse adapter: rakendus, mis võtab virtuaalse liidese ja edastab valitud liikluse kohalikku SOCKS-kuulajasse. Ahelast saab rakendus, adapter, SOCKS-kuulaja, SSH-ühendus, sihtkoht.

Paigalda adapter, anna sellele VPN-luba ja vali rakendused või marsruudid, mida see püüab. Olekuriba võtmeikoon tähistab seejärel adapterit, mitte eraldi kommertsVPN-i. Android lubab ühe aktiivse VPN-teenuse ühenduse kasutajaprofiili kohta, seega teise VPN-rakenduse käivitamine ei lisa ahelale kihti: see võistleb sama rolli pärast.

See on ka samm, kus õnnestunud test võib sind eksitada. Kui adapter on seadistatud püüdma ainult brauserit, mille juba proxyle suunasid, töötab kõik ega ole midagi muud kaetud. Loe püüdmisnimekirja enne, kui järeldad, et seade on tunnelisse viidud.

Hoia SSH-transport püüdmisest väljas

SSH-ühendus ise ei tohi tagasi sattuda SOCKS-tunnelisse, mida ta ülal hoiab. Kui adapter püüab SSH-rakenduse liikluse, sõltub tunnel ühendusest, mis ootab tunnelit, ja tulemuseks on silmus, mis takerdub või ebaõnnestub kohe, kui adapter käivitub.

Integreeritud teostused kaitsevad oma transport-pesandit. Eraldi rakendustega on vaja toetatud erandit: jäta SSH-rakendus püüdmisest välja või välista SSH-lõpp-punkt aadressi järgi. Mõlemal on oma hind. Terve terminalirakenduse välistamine eemaldab tunnelist ka selle mitteseotud võrgutegevuse, ja aadressierand katkeb, kui serveri aadress muutub või kui nimi laheneb järgmisel ühendusel teisiti.

Kontrolli erandit väljastpoolt: ühenda adapter uuesti ja kinnita seejärel, et SSH-sessioon jääb püsima ja proxy kaudu tehtud päring teatab endiselt serveri aadressi. Sessioon, mis töötab kuni adapteri käivitumiseni ja külmub siis, ongi silmus.

Jälgi DNS-i ja UDP-d ahela lõpuni

OpenSSH dünaamiline edastus kannab TCP-ühendusi. See ei ole UDP-associate ega ICMP-transport ja adapter ei saa UDP-pakette vastu võttes UDP-edastust leiutada. Kõik, mis nõuab UDP-d, sealhulgas QUIC ja WebRTC-meedia, kas ebaõnnestub või langeb tagasi TCP-le, sõltuvalt rakendusest.

DNS vajab oma otsust. Rakendus, mis lahendab nime kohapeal, saadab päringu enne ühendamist tavalise resolveri kaudu, nii et tunnel kannab ühendust, kuid mitte otsingut. Proxy-teadlik klient kaug-DNS-i valikuga väldib seda; püütud rakendus ilma selleta mitte. Kontrolli, milline resolver vastas, selle asemel et eeldada, et adapter seda muutis.

Hoia SOCKS-kuulaja loopbacki küljes, kontrolli SSH-serveri host-võtit esimesel kasutusel ja jäta lõppsaidile tavaline HTTPS-valideerimine alles. SSH kaitseb telefoni ja serveri vahelist lõiku; see ei krüpteeri seda, mida server pärast teeb.

Kontrolli kahte eluiga ja otsusta

Adapteril ja SSH-sessioonil on eraldi eluead. Kui SSH katkeb, samal ajal kui adapter jätkab püüdmist, võivad rakendused rippuma jääda ilma nähtava veata, sest nende paketid sisenevad endiselt virtuaalsesse liidesesse, millel pole enam toimivat väljapääsu. Kui adapter peatub, lähevad rakendused kas otse või blokeeritakse, sõltuvalt seadme VPN-poliitikast.

Testi mõlemat suunda meelega: tapa SSH-sessioon adapteri töötamise ajal ja peata seejärel adapter, kui SSH jääb püsti. See, mida telefon kummagi puhul teeb, on poliitika, mida sa tegelikult juurutad, ükskõik mida paigaldusjuhised väitsid.

Kui töövoog vajab kogu seadme katvust etteaimatava rikkerežiimiga, on aus vastus päris IP VPN või selle ahela jaoks mõeldud hooldatud adapter. Kõrvuti mitteseotud püüdmisrakendusega jäetud shell-sessioon ei ole hooldatud seadme tunnel; need on kaks komponenti, millel pole kokkulepet selle kohta, mis juhtub, kui üks neist lõpeb.