Përcjellje lokale SSH drejt një proxy HTTP ekzistues: dy adresa loopback

Proxy-i juaj i miratuar ekzekutohet në një host kërcimi ku dëgjon vetëm në loopback, kështu që asgjë jashtë atij makinerie nuk mund ta arrijë. Nuk ju duhet VPN apo një proxy e re; ju duhet një port i atij makinerie i sjellë në një port tuajin. Një përcjellje lokale bën pikërisht këtë, dhe kërkon një komandë plus një rregullim të aplikacionit. Konfuzioni zakonisht vjen nga përzierja se cila adresë loopback i përket cilit makinë.

Vendosni nëse ekziston tashmë një proxy fikse

Kjo teknikë përcjell një shërbim që është tashmë në punë. Nëse hosti i largët ka vetëm një demon SSH dhe asnjë proxy, asnjë sasi përcjelljeje nuk krijon një, dhe lidhja do të refuzohet nga ana e largët. Konfirmoni që proxy-i është i lidhur, cili është porti i tij, dhe nëse dëgjon në 127.0.0.1 apo në një adresë specifike ndërfaqeje, sepse pikërisht ajo adresë është objektivi që përcjellja duhet të synojë.

Konfirmimi i kësaj fillimisht ju kursen nga korrigjimi i një tuneli që nuk ishte lidhur kurrë me asgjë.

Ndërtoni përcjelljen dhe lexoni komandën

Forma që dëshironi lidh një port loopback në laptopin tuaj dhe e lidh atë, nga ana e serverit, me adresën e proxy-t siç e sheh serveri.

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

-N shtyp një komandë të largët dhe -T shtyp ndarjen e termios, sepse dëshironi një tunel dhe jo një shell. Adresa e parë loopback është aty ku dëgjon laptopi; e dyta zgjidhet nga serveri SSH, pra 127.0.0.1 atje nënkupton proxy-n në atë makinë. ExitOnForwardFailure e bën komandën të dështojë me zë nëse porti lokal është tashmë i zënë, në vend që të nisë një sesion që nuk përcjell asgjë. Shkruani adresën e synuar ashtu siç e zgjidh serveri, sepse një emër që mund ta zgjidhë vetëm laptopi juaj do të dështojë në anën tjetër.

Politika e vetë serverit zbatohet para se ndonjë gjë nga kjo të funksionojë. AllowTcpForwarding duhet ta lejojë, dhe PermitOpen mund të kufizojë se cilat destinacione dhe porte mund të arrijë një sesion, kështu që një përcjellje që klienti e pranon mund të refuzohet ende nga serveri. Refuzimi shfaqet si gabim përcjelljeje ose kanali te klienti, dhe leximi i atij mesazhi është më i shpejtë sesa redaktimi i komandës.

Drejtoni një aplikacion te përcjellja

Konfiguroni aplikacionin të përdorë një proxy HTTP në http://127.0.0.1:13128, me kredenciale nëse proxy-i i largët i kërkon ato. Mbani verifikimin e certifikatave të vetë aplikacionit për destinacionet HTTPS, pasi tuneli i proxy-t nuk e zëvendëson atë. Kjo është një përcjellje fikse e një shërbimi, prandaj aplikacionit duhet t’i thuhet se ekziston një proxy, në vend që ta lini ta zbulojë vetë.

Një kontroll i shpejtë përpara çdo konfigurimi të përhershëm: curl -x http://127.0.0.1:13128 -I https://example.com, i cili ushtron metodën HTTP CONNECT që proxy-i duhet të mbështesë.

Mbajeni autoritetin aty ku ishte

Proxy-i i largët vendos ende cilat destinacione dhe metoda lejon, dhe një hyrje SSH nuk duhet t’i japë në heshtje çdo llogarie një rele web të përgjithshme. Lidhja me 127.0.0.1 në laptop shmang publikimin e portit në rrjetin tuaj lokal, dhe nuk e bën portin privat nga proceset e tjera në të njëjtën makinë. Zëvendësimi i asaj lidhjeje me një adresë wildcard për të ndarë proxy-n është mënyra se si krijohet një rele e hapur e pamenaxhuar.

Transporti SSH mbron kërcimin deri te serveri. Përtej asaj pike proxy-i hap lidhjen e vet, kështu që një kërkesë HTTP e thjeshtë drejt një destinacioni mbetet e thjeshtë edhe përtej serverit, ndonëse segmenti i parë ishte i kriptuar.

Verifikoni të dy skajet, pastaj pastroni

Konfigurimi i tunelit lokal dhe suksesi i shërbimit të largët janë rezultate të ndryshme, dhe statusi i daljes së komandës ju tregon vetëm për të parin. Kontrolloni që dëgjuesi ekziston me ss -ltn, pastaj bëni një kërkesë të lejuar të aplikacionit dhe një kërkesë që proxy-i duhet ta refuzojë. Nëse të dy sillen siç pritet, rruga është e vërtetë; nëse tuneli është lart dhe çdo kërkesë dështon, proxy-i po refuzon ose nuk arrin destinacionin.

Kur mbaroni, ndalni procesin SSH që e zotëron, hiqni rregullimin e proxy-t nga aplikacioni dhe konfirmoni që porti lokal ka ikur, në vend që të lini një dëgjues që mbijeton detyrën.