SSH dinamičko prosljeđivanje kao SOCKS proxy preko vašeg VPN-a
Aplikacija koja govori samo SOCKS nema proxy odredište na običnom VPN-u. Dva skoka, jedan loopback slušalac i jedno traženje imena koje SSH server mora obaviti sam.
Aplikacija koja govori samo SOCKS nema s čim razgovarati na običnom VPN-u, jer tunel prenosi pakete a aplikacija želi proxy odredište. OpenSSH može osigurati to odredište kada vlasnik pristupa to dopusti, jer dinamičko prosljeđivanje pretvara jednu SSH sesiju u lokalni proxy. Zatim postoje dva skoka koja treba držati odvojeno: tunel koji doseže SSH host i veza koju taj host zatim otvara. Njihovo razdvajanje objašnjava i zašto raspored radi i što on nikada neće učiniti.
Šta SSH slušalac postaje, a šta ne
Dinamičko prosljeđivanje prisiljava SSH klijenta da sluša lokalno i govori SOCKS4 ili SOCKS5 sa svim što se poveže. Svaki zahtjev imenuje odredište i SSH server otvara dalju vezu, zbog čega se traženje odredišta može dogoditi na suprotnoj strani. To je TCP prosljeđivanje na razini aplikacije, a ne VPN za cijeli uređaj. Ne nosi UDP asocijaciju, ni ICMP, ni ništa za aplikacije koje potpuno ignoriraju proxy postavke. Skok od SSH servera do aplikacije također nije unutar vašeg tunela, što je važno kada odredište prihvaća promet samo iz poznatih mreža.
Preduvjeti su stvarni: ruta do SSH hosta, ovlašteni račun, provjereni ključ hosta servera i dopuštenje za prosljeđivanje. Nijedan od njih ne stvara proxy, a posljednji obično prvi nedostaje. Potvrdite sva četiri prije nego što bilo što drugo budete tražili, jer kvar izgleda isto s klijenta, koji god nedostajao.
Pokrenite ga na loopbacku s izričitim portom
Odaberite nekorišteni lokalni port i izričito ga vežite na loopback umjesto da adresu izostavite. Tri opcije ispod postoje svaka zbog jednog razloga.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]
-N preskače udaljenu naredbu a -T preskače pseudo-terminal, pa sesija postoji samo radi prosljeđivanja. ExitOnForwardFailure natjera klijenta da izađe kada slušalac ne može nastati, umjesto da radi bez prosljeđivanja koje ste tražili. ControlPath=none drži sesiju izvan postojeće multipleksirane veze koja bi mogla dodati vlastita prosljeđivanja. Loopback drži slušalac izvan LAN-a, ali na dijeljenom stroju to nije granica ovlaštenja, jer mu i drugi lokalni procesi mogu pristupiti. Referenca OpenSSH klijenta dokumentira sve te zastavice, a upozorenje o loopbacku slijedi iz onoga što je socket koji sluša.
Pošaljite imena kroz proxy, a ne oko njega
SOCKS5 klijent može sam razriješiti odredište ili zamoliti proxy da to učini, a taj izbor odlučuje koji će resolver odgovoriti. S socks5h curl šalje ime hosta kroz proxy, pa se traženje događa na SSH serveru. S običnim socks5 laptop prvo razrješava i putuje samo veza, što tiho poništava svrhu kada je ime interno. Zahtjev ispod također čisti popis bez proxyja, pa naslijeđena vrijednost NO_PROXY ne može ga usmjeriti oko proxyja.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health
Provjera certifikata i vlastita prijava aplikacije i dalje vrijede, jer proxy ne zamjenjuje ni jedno ni drugo. Ostaju dva traženja: laptop mora doseći SSH host kroz dopuštenu VPN i DNS putanju, a SSH server mora sam razriješiti ime aplikacije. Drugo je moguće provjeriti zasebno prije nego bilo koji promet prođe kroz proxy.
ssh [email protected] getent hosts app.corp.example
Dokažite jedno dopušteno odredište, pa ugasite sesiju
Testirajte odredište koje politika dopušta i ono koje bi trebala odbiti, jer ispravno prosljeđivanje dokazuje samo da slušalac radi i ništa više. Aplikacija vidi izvornu adresu koju SSH server odabere, a to nije tunelska adresa vašeg laptopa. Gdje udaljena strana bilježi veze po izvoru, ta razlika je prvo što treba provjeriti kada zahtjev bude odbijen.
Zaustavite sesiju kroz proces koji ju posjeduje, a ne ubijanjem nepovezanog shella. Zatim potvrdite da je slušalac nestao, jer port koji još odgovara je sesija koju zapravo niste zatvorili. Uklonite samo proxy postavku koju je ova vježba uvela, a ostatak konfiguracije aplikacije ostavite na miru. Nadzirani terminal koji drži pravilo prosljeđivanja nije usluga, i trajni proxy traži odobren životni ciklus, a ne zaboravljeni prozor.
ss -ltn | grep 1080
Kvarovi koje ovaj raspored ne može ispraviti
Neki simptomi pokazuju ravno na gornja ograničenja, a njihovo rano prepoznavanje štedi jedno poslijepodne traženja problema s proxyjem. Tablica povezuje ono što vidite s onim što to obično znači. Sve u posljednjem stupcu je pitanje dizajna, a ne pogreška u konfiguraciji.
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
Prva tri retka su ona koja ljudi pogrešno dijagnosticiraju, jer svaki proizvodi pokušaj veze umjesto pogreške o samom proxyju. Ime koje se razrješava na laptopu ne govori ništa o resolveru servera, a kvar se umjesto toga čita kao problem s certifikatom ili vremenskom ograničenju. Aplikacije samo s UDP-om stoje izvan dizajna, a ne pokvarene unutar njega, i nikakva dodatna ssh opcija to ne mijenja. Redak o pregledniku je uobičajeni podsjetnik da proxy postavke vrijede za svaku aplikaciju zasebno. Posljednji redak je razlog zašto provjera zatvaranja postoji: port koji još sluša znači da ga sad posjeduje nešto drugo.