Maabot ang Umiiral na HTTP o SOCKS Proxy sa Pamamagitan ng SSH
Maabot ang malayong loopback HTTP o SOCKS proxy sa pamamagitan ng SSH nang hindi inilalantad sa publiko ang listener nito.
Kung ang relay.example.net ay nagpapatakbo na ng SOCKS sa sarili nitong 127.0.0.1:1080, ipasa ang access sa halip na ilantad sa publiko ang listener na iyon:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Endpoint | Papel |
|---|---|
Laptop 127.0.0.1:1081 | Ang SOCKS address na iko-configure sa application ng laptop. |
Relay 127.0.0.1:1080 | Ang umiiral na proxy na naaabot mula sa panig ng SSH server. |
Ang syntax ng lokal na pagpapasa ay nagtatalaga ng nakapirming destinasyon sa panig ng server. Ang HTTP proxy sa malayong loopback port 3128 o endpoint ng intranet tulad ng proxy.internal.example:8080 ay gumagana sa parehong prinsipyo. I-configure ang client para sa umiiral na HTTP protocol na iyon at account; ang pagdala nito sa SSH ay hindi lumilikha ng SOCKS o HTTPS listener na may TLS.
Pinipili pa rin ng umiiral na serbisyo ang mga sinusuportahang bersyon ng protocol, authentication, destinasyon at huling labasan. Kung ibang SSH process ang gumawa ng malayong proxy na iyon, dapat manatiling buhay ang dalawang process. Ang rutang laptop→relay→gateway ay nag-iiwan sa website na makita ang huling palabas na koneksyon, hindi isang pagkakakilanlang inilalaan ng lokal na port 1081.
Panatilihing tahasang lokal ang binding ng laptop. Binabago ng mas malawak na pagkakalantad kung sino ang makakaabot sa serbisyo, at hindi nagdaragdag ng SOCKS password sa listener ang pag-login sa SSH. Kung tinanggihan, suriin ang listener ng laptop, transport ng SSH at malayong proxy bilang magkakahiwalay na yugto.