Lokal na pagpapasa ng SSH sa umiiral na HTTP proxy: dalawang loopback address

Ang iyong aprubadong proxy ay tumatakbo sa isang jump host kung saan nakikinig lamang ito sa loopback, kaya walang bagay sa labas ng makinang iyon ang makakaabot dito. Hindi mo kailangan ng VPN o bagong proxy; kailangan mo ng isang port ng makinang iyon na dalhin sa isang port mo. Ginagawa ng lokal na pagpapasa ang eksaktong iyon, at nangangailangan ito ng isang utos at isang setting ng aplikasyon. Ang kalituhan ay kadalasang nagmumula sa pagpapalit kung aling loopback address ang pag-aari ng aling makina.

Magpasya kung mayroon nang nakapirming proxy

Ipinapasa ng teknik na ito ang isang serbisyong tumatakbo na. Kung ang malayong host ay may SSH daemon lamang at walang proxy, walang dami ng pagpapasa ang makakagawa ng isa, at tatanggihan ang koneksyon mula sa malayong panig. Tiyakin na nakatali ang proxy, ano ang port nito, at kung nakikinig ito sa 127.0.0.1 o sa isang partikular na interface address, dahil ang address na iyon ang dapat na target ng pagpapasa.

Ang pagtiyak nito muna ay ililigtas ka sa pag-debug ng tunnel na kailanman ay hindi nakakonekta sa anuman.

Buuin ang pagpapasa at basahin ang utos

Ang anyong gusto mo ay nagtatali ng isang loopback port sa iyong laptop at ikinokonekta ito, mula sa panig ng server, sa address ng proxy ayon sa nakikita ng server.

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

Pinipigilan ng -N ang isang malayong utos at pinipigilan ng -T ang paglalaan ng termios, dahil gusto mo ng tunnel at hindi shell. Ang unang loopback address ay kung saan nakikinig ang laptop; ang pangalawa ay nireresolba ng SSH server, kaya ang 127.0.0.1 doon ay nangangahulugang ang proxy sa makinang iyon. Pinapabagsak ng ExitOnForwardFailure ang utos nang malakas kung okupado na ang lokal na port, sa halip na magsimula ng sesyon na walang ipinapasa. Isulat ang target address ayon sa pagresolba ng server, dahil ang pangalang kayang iresolba lamang ng iyong laptop ay mabibigo sa kabilang panig.

Nalalapat ang sariling patakaran ng server bago gumana ang alinman dito. Dapat payagan ito ng AllowTcpForwarding, at maaaring limitahan ng PermitOpen kung aling mga destinasyon at port ang maaabot ng isang sesyon, kaya ang pagpapasang tinatanggap ng kliyente ay maaari pa ring tanggihan ng server. Lumalabas ang pagtanggi bilang error sa pagpapasa o channel sa kliyente, at ang pagbasa ng mensaheng iyon ay mas mabilis kaysa sa pag-edit ng utos.

Itutok ang isang aplikasyon sa pagpapasa

I-configure ang aplikasyon na gumamit ng HTTP proxy sa http://127.0.0.1:13128, may mga kredensyal kung kailanganin ng malayong proxy. Panatilihin ang sariling pagpapatotoo ng sertipiko ng aplikasyon para sa mga destinasyong HTTPS, dahil hindi ito pinapalitan ng tunnel ng proxy. Ito ay isang nakapirming pagpapasa ng isang serbisyo, kaya kailangang sabihan ang aplikasyon na may proxy sa halip na hayaang matuklasan nito ang isa.

Isang mabilis na pagsusuri bago mag-configure ng anumang permanente: curl -x http://127.0.0.1:13128 -I https://example.com, na nagsasanay sa HTTP CONNECT method na dapat suportahan ng proxy.

Panatilihin ang awtoridad kung saan ito naroon

Ang malayong proxy pa rin ang nagpapasya kung aling mga destinasyon at pamamaraan ang pinapayagan nito, at ang pag-login sa SSH ay hindi dapat tahimik na magbigay ng pangkalahatang web relay sa bawat account. Ang pagtali sa 127.0.0.1 sa laptop ay umiiwas sa paglalathala ng port sa iyong lokal na network, at hindi nito ginagawang pribado ang port mula sa ibang proseso sa parehong makina. Ang pagpapalit ng taling iyon ng wildcard address upang ibahagi ang proxy ay ang paraan kung paano nabubuo ang isang hindi pinamamahalaang bukas na relay.

Pinoprotektahan ng transportasyong SSH ang paglundag hanggang sa server. Lampas sa puntong iyon binubuksan ng proxy ang sarili nitong koneksyon, kaya ang isang simpleng kahilingang HTTP sa isang destinasyon ay nananatiling simple lampas sa server, kahit na ang unang bahagi ay naka-encrypt.

I-verify ang dalawang dulo, pagkatapos ay linisin

Ang pag-set up ng lokal na tunnel at ang tagumpay ng malayong serbisyo ay magkaibang resulta, at ang exit status ng utos ay nagsasabi lamang tungkol sa una. Suriin kung may nakikinig gamit ang ss -ltn, pagkatapos ay gumawa ng pinapayagang kahilingan ng aplikasyon at isang kahilingang dapat tanggihan ng proxy. Kung ang dalawa ay kumilos ayon sa inaasahan, totoo ang landas; kung nakabukas ang tunnel at nabibigo ang bawat kahilingan, tumatanggi ang proxy o hindi nito maabot ang destinasyon.

Kapag tapos ka na, ihinto ang prosesong SSH na nagmamay-ari nito, alisin ang setting ng proxy mula sa aplikasyon, at tiyakin na wala na ang lokal na port sa halip na mag-iwan ng nakikinig na mas matagal pa sa gawain.