Dinamično posredovanje SSH kot proxy SOCKS prek vašega VPN
Aplikacija, ki govori samo SOCKS, na običajnem VPN nima nobene končne točke proxy. Dva skoka, en loopback poslušalec in eno iskanje imena, ki ga mora opraviti sam strežnik SSH.
Aplikacija, ki govori samo SOCKS, se na običajnem VPN nima s kom pogovarjati, ker tunel prenaša pakete, aplikacija pa želi končno točko proxy. OpenSSH lahko to točko zagotovi, ko lastnik dostopa to dovoli, ker dinamično posredovanje spremeni eno sejo SSH v krajevni proxy. Nato je treba naravnost držati dva skoka: tunel, ki doseže gostitelja SSH, in povezavo, ki jo ta gostitelj nato odpre. Njuna ločitev pojasni tako, zakaj ureditev deluje, kot tudi, česa ne bo nikoli naredila.
Kaj poslušalec SSH postane in kaj ne
Dinamično posredovanje prisili odjemalca SSH, da posluša krajevno in govori SOCKS4 ali SOCKS5 z vsem, kar se poveže. Vsaka zahteva poimenuje cilj in strežnik SSH odpre nadaljnjo povezavo, zato se iskanje cilja lahko zgodi na drugi strani. To je posredovanje TCP na ravni aplikacije, ne VPN za celotno napravo. Ne prenaša nobene asociacije UDP, nobenega ICMP in ničesar za aplikacije, ki popolnoma prezrejo nastavitve proxy. Tudi skok s strežnika SSH do aplikacije ni znotraj vašega tunela, kar je pomembno, ko cilj sprejema promet le iz znanih omrežij.
Predpogoji so resnični: pot do gostitelja SSH, pooblaščen račun, preverjen ključ gostitelja strežnika in dovoljenje za posredovanje. Nobenega od njih ne ustvari proxy, zadnji pa običajno manjka prvi. Potrdite vse štiri, preden odpravljate karkoli drugega, ker je z vidika odjemalca napaka videti enako, katera koli manjka.
Zaženite ga na loopbacku z izrecnimi vrati
Izberite neuporabljena krajevna vrata in jih izrecno povežite z loopbackom, namesto da naslov izpustite. Tri spodnje možnosti obstajajo vsaka iz enega razloga.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N preskoči oddaljeni ukaz in -T preskoči psevdovmesnik, tako da seja obstaja le za posredovanje. ExitOnForwardFailure prisili odjemalca, da se zaključi, ko poslušalca ni mogoče ustvariti, namesto da bi deloval brez zahtevanega posredovanja. ControlPath=none drži sejo zunaj obstoječe multipleksirane povezave, ki bi lahko dodala svoja posredovanja. Loopback drži poslušalca zunaj LAN-a, a na deljenem računalniku to ni meja pooblastil, ker lahko do njega pridejo tudi drugi krajevni procesi. Referenca odjemalca OpenSSH dokumentira vse te stikala in opozorilo o loopbacku izhaja iz tega, kaj je poslušajoča vtičnica.
Pošiljajte imena skozi proxy, ne okoli njega
Odjemalec SOCKS5 lahko cilj razreši sam ali prosi proxy, naj to stori, in ta izbira odloči, kateri razreševalnik bo odgovoril. S socks5h curl pošlje ime gostitelja skozi proxy, zato se iskanje zgodi na strežniku SSH. Z običajnim socks5 prenosnik najprej razreši sam in potuje le povezava, kar tiho izniči smisel, ko je ime notranje. Zahteva spodaj tudi izprazni seznam brez proxyja, tako da podedovana vrednost NO_PROXY ne more iti okoli proxyja.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthPreverjanje potrdila in lastna prijava aplikacije še vedno veljata, ker proxy ne nadomesti nobenega od obeh. Ostaneta dve iskanji: prenosnik mora doseči gostitelja SSH po dovoljeni poti VPN in DNS, strežnik SSH pa mora sam razrešiti ime aplikacije. Drugo je mogoče preizkusiti ločeno, preden gre kakršen koli promet skozi proxy.
ssh [email protected] getent hosts app.corp.exampleDokažite en dovoljen cilj in nato zaprite sejo
Preizkusite cilj, ki ga politika dovoli, in tistega, ki bi ga morala zavrniti, ker delujoče posredovanje dokazuje le, da poslušalec deluje, in nič več. Aplikacija vidi izvorni naslov, ki ga izbere strežnik SSH, in to ni naslov tunela vašega prenosnika. Kjer oddaljena stran beleži povezave po izvoru, je ta razlika prva stvar, ki jo je treba preveriti, ko je zahteva zavrnjena.
Ustavite sejo prek procesa, ki jo ima v lasti, namesto da ubijete nepovezano lupino. Nato potrdite, da poslušalca ni več, ker so vrata, ki še odgovarjajo, seja, ki je v resnici niste zaprli. Odstranite le nastavitev proxyja, ki jo je uvedla ta vaja, in pustite ostalo konfiguracijo aplikacije pri miru. Nenadzorovan terminal s pravilom posredovanja ni storitev in trajni proxy potrebuje odobren življenjski cikel, ne pozabljeno okno.
ss -ltn | grep 1080Napake, ki jih ta ureditev ne more odpraviti
Nekateri simptomi kažejo naravnost na zgornje meje in njihovo zgodnje prepoznavanje prihrani popoldne odpravljanja napak proxyja. Tabela poveže to, kar vidite, s tem, kar to običajno pomeni. Karkoli v zadnjem stolpcu je vprašanje zasnove, ne napaka v 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 |
Prve tri vrstice so tiste, ki jih ljudje napačno diagnosticirajo, ker vsaka ustvari poskus povezave namesto napake o samem proxyju. Ime, ki se razreši na prenosniku, ne pove ničesar o razreševalniku strežnika, napaka pa se namesto tega bere kot težava s potrdilom ali časovno omejitvijo. Aplikacije samo z UDP stojijo zunaj zasnove, ne pokvarjene v njej, in nobena dodatna možnost ssh tega ne spremeni. Vrstica o brskalniku je običajen opomin, da nastavitve proxyja veljajo za vsako aplikacijo posebej. Zadnja vrstica je razlog, da preverjanje ob zaprtju obstaja: vrata, ki še poslušajo, pomenijo, da jih zdaj ima v lasti nekaj drugega.