SSH bidezko tokiko birbidalketa existitzen den HTTP proxy batera: bi loopback helbide

Zure proxy onartuak jauzi-ostalari batean egiten du lan, non loopbackean soilik entzuten duen, beraz makinatik kanpoko ezerk ezin du hara iritsi. Ez duzu VPN bat edo proxy berri bat behar; makina horretako portu bat zure portu batera eramanda behar duzu. Tokiko birbidalketa batek zehazki hori egiten du, eta komando bat eta aplikazioaren ezarpen bat behar ditu. Nahastea loopback helbide bakoitza zein makinari dagokion nahastean sortu ohi da.

Erabaki proxy finko bat badagoen jada

Teknika honek jadanik martxan dagoen zerbitzu bat birbidaltzen du. Urruneko ostalariak SSH daemon bat baino ez badu eta proxyrik ez badu, birbidalketa-kopuru edozek ez du bat sortuko, eta konexioa urruneko aldetik ukatuko da. Egiaztatu proxyak lotuta dagoela, zein den bere portua, eta 127.0.0.1n edo interfaze-helbide jakin batean entzuten duen, helbide horixe baita birbidalketak helburutzat hartu behar duena.

Hori lehenengo egiaztatzeak inoiz ezeri konektatu ez zitzaion tunela arazteko lana aurrezten dizu.

Eraiki birbidalketa eta irakurri komandoa

Nahi duzun formak loopback portu bat lotzen du zure eramangarrian, eta zerbitzariaren aldetik proxyaren helbidera konektatzen du, zerbitzariak ikusten duen bezala.

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

-N aukerak urruneko komandoa isilarazten du eta -T aukerak termios esleipena isilarazten du, tunela nahi duzulako, ez shell bat. Lehen loopback helbidea eramangarriak entzuten duen tokia da; bigarrena SSH zerbitzaritik ebazten da, beraz 127.0.0.1 hango proxyak makina horretan esan nahi du. ExitOnForwardFailure aukerak komandoa ozenki huts egitea eragiten du tokiko portua jada hartuta badago, ezer birbidaltzen ez duen saio bat hasi ordez. Idatzi helburu-helbidea zerbitzariak ebazten duen bezala, zure eramangarriak soilik ebatz dezakeen izen batek beste aldean huts egingo baitu.

Zerbitzariaren beraren politikak hartzen du indarra, horietako ezerk lan egin aurretik. AllowTcpForwarding aukerak baimendu behar du, eta PermitOpen aukerak mugatu dezake saio batek zein helmuga eta portutara irits daitekeen, beraz bezeroak onartzen duen birbidalketa bat zerbitzariak oraindik uka dezake. Ukazioa birbidalketa- edo kanal-errore gisa agertzen da bezeroan, eta mezu hori irakurtzea komandoa editatzea baino azkarragoa da.

Zuzendu aplikazio bat birbidalketara

Konfiguratu aplikazioa http://127.0.0.1:13128 helbidean HTTP proxy bat erabiltzeko, urruneko proxyak behar baditu kredentzialekin. Mantendu aplikazioaren beraren ziurtagiri-egiaztapena HTTPS helmugentzat, proxy tunelak ez baitu hura ordezkatzen. Hau zerbitzu bakarraren birbidalketa finkoa da, beraz aplikazioari proxy bat badagoela esan behar zaio, hark berak aurki dezan utzi ordez.

Ezarpen iraunkorrik egin aurretik proba azkar bat: curl -x http://127.0.0.1:13128 -I https://example.com, proxyak onartu behar duen HTTP CONNECT metodoa praktikatzen duena.

Eutsi agintea zegoen lekuan

Urruneko proxyak oraindik erabakitzen du zein helmuga eta metodo baimentzen dituen, eta SSH saio-hasierak ez luke isilpean kontu bakoitzari web errele orokor bat emango. Eramangarrian 127.0.0.1ra lotzeak portua zure tokiko sarera argitaratzea saihesten du, eta ez du portua pribatu egiten makina bereko beste prozesuetatik. Lotura hori wildcard helbide batekin ordezkatzea proxya partekatzeko da kudeatu gabeko errele ireki bat sortzeko modua.

SSH garraioak zerbitzariranzko jauzia babesten du. Puntu horretatik aurrera proxyak bere konexioa irekitzen du, beraz helmuga baterako HTTP eskaera soil bat soilik jarraitzen da zerbitzariaren ondoren, lehen segmentua zifratuta egon bazen ere.

Egiaztatu bi muturrak, eta gero garbitu

Tokiko tunelaren konfigurazioa eta urruneko zerbitzuaren arrakasta emaitza desberdinak dira, eta komandoaren irteera-egoerak lehenengoaz soilik hitz egiten dizu. Egiaztatu entzulea badagoela ss -ltn erabiliz, eta gero egin baimendutako aplikazio-eskaera bat eta proxyak ukatu beharko lukeen eskaera bat. Biak espero bezala portatzen badira, bidea benetakoa da; tunela martxan badago eta eskaera guztiek huts egiten badute, proxyak ukatzen du edo ezin du helmugara iritsi.

Amaitzean, gelditu tunela duen SSH prozesua, kendu proxyaren ezarpena aplikaziotik, eta egiaztatu tokiko portua desagertu dela, zeregina biziraungo lukeen entzule bat utzi ordez.