Lokalno posredovanje SSH do obstoječega proxyja HTTP: dva naslova loopback

Vaš odobreni proxy teče na preskočnem gostitelju, kjer posluša samo na loopback, zato nič zunaj tega stroja ne more priti do njega. Ne potrebujete VPN ali novega proxyja; potrebujete ena vrata tega stroja, prenesena na ena svojih vrat. Lokalno posredovanje naredi točno to in zahteva en ukaz ter eno nastavitev aplikacije. Zmeda običajno nastane zaradi mešanja, kateri naslov loopback pripada kateremu stroju.

Ugotovite, ali fiksni proxy že obstaja

Ta tehnika posreduje storitev, ki že teče. Če ima oddaljeni gostitelj samo demon SSH in nobenega proxyja, nobena količina posredovanja ne ustvari enega, povezava pa bo zavrnjena z oddaljene strani. Potrdite, da je proxy vezan, katera so njegova vrata in ali posluša na 127.0.0.1 ali na določenem naslovu vmesnika, ker je ta naslov cilj, ki ga mora posredovanje doseči.

Če to preverite najprej, si prihranite odpravljanje napak na tunelu, ki ni bil nikoli povezan z ničimer.

Zgradite posredovanje in preberite ukaz

Oblika, ki jo želite, veže vrata loopback na vašem prenosniku in jih s strežnikove strani poveže z naslovom proxyja, kot ga vidi strežnik.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N zaduši oddaljeni ukaz, -T pa zaduši dodeljevanje termios, ker želite tunel in ne lupine. Prvi naslov loopback je tam, kjer posluša prenosnik; drugega razreši strežnik SSH, zato 127.0.0.1 tam pomeni proxy na tem stroju. ExitOnForwardFailure poskrbi, da ukaz glasno spodleti, če so lokalna vrata že zasedena, namesto da bi začel sejo, ki nič ne posreduje. Ciljni naslov zapišite tako, kot ga razreši strežnik, ker ime, ki ga lahko razreši samo vaš prenosnik, bo na drugi strani spodletelo.

Lastna politika strežnika velja, preden karkoli od tega deluje. AllowTcpForwarding mora to dovoliti, PermitOpen pa lahko omeji, do katerih ciljev in vrat lahko seja pride, zato lahko strežnik posredovanje, ki ga odjemalec sprejme, vseeno zavrne. Zavrnitev se pri odjemalcu pokaže kot napaka posredovanja ali kanala, in branje tega sporočila je hitrejše od urejanja ukaza.

Usmerite eno aplikacijo na posredovanje

Nastavite aplikacijo, da uporablja proxy HTTP na http://127.0.0.1:13128, s poverilnicami, če jih oddaljeni proxy zahteva. Ohranite lastno preverjanje potrdil aplikacije za cilje HTTPS, saj tunel proxyja tega ne nadomesti. To je fiksno posredovanje ene storitve, zato je treba aplikaciji povedati za proxy, namesto da jo pustite, da ga odkrije sama.

Hitro preverjanje pred kakršno koli trajno nastavitvijo: curl -x http://127.0.0.1:13128 -I https://example.com, kar preizkusi metodo HTTP CONNECT, ki jo mora proxy podpirati.

Ohranite pooblastilo tam, kjer je bilo

Oddaljeni proxy še vedno odloča, katere cilje in metode dovoljuje, in prijava SSH ne bi smela vsakemu računu tiho dati splošnega spletnega releja. Vezava na 127.0.0.1 na prenosniku se izogne objavi vrat v vašem lokalnem omrežju in vrat ne naredi zasebnih pred drugimi procesi na istem stroju. Zamenjava te vezave z naslovom wildcard za deljenje proxyja je način, kako nastane neupravljani odprti relej.

Transport SSH zaščiti skok do strežnika. Za to točko proxy odpre svojo povezavo, zato običajna zahteva HTTP do cilja ostane običajna tudi za strežnikom, čeprav je bil prvi odsek šifriran.

Preverite oba konca in nato počistite

Nastavitev lokalnega tunela in uspeh oddaljene storitve sta različna rezultata, in izhodni status ukaza vam pove le o prvem. S pomočjo ss -ltn preverite, ali poslušalec obstaja, nato izvedite dovoljeno zahtevo aplikacije in zahtevo, ki bi jo proxy moral zavrniti. Če se oba obnašata po pričakovanjih, je pot resnična; če tunel deluje in vsaka zahteva spodleti, proxy zavrača ali ne more doseči cilja.

Ko končate, ustavite proces SSH, ki ga ima v lasti, odstranite nastavitev proxyja iz aplikacije in potrdite, da so lokalna vrata izginila, namesto da pustite poslušalca, ki bo nalogo preživel.