Доступ да існуючага HTTP- або SOCKS-проксі праз SSH
Атрымайце доступ да аддаленага loopback HTTP- або SOCKS-проксі праз SSH, не выкрываючы яго слухач публічна.
Калі relay.example.net ужо запускае SOCKS на сваім 127.0.0.1:1080, перадавайце доступ, а не выкрывайце гэты слухач публічна:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Канчатковы пункт | Роля |
|---|---|
Ноўтбук 127.0.0.1:1081 | Адрас SOCKS, які трэба наладзіць у праграме ноўтбука. |
Рэлей 127.0.0.1:1080 | Існуючы проксі, дасяжны з боку сервера SSH. |
Сінтаксіс лакальнага перанакіравання прызначае фіксаваны пункт прызначэння на бок сервера. HTTP-проксі на аддаленым loopback-порце 3128 або ўнутраны пункт такі як proxy.internal.example:8080 працуюць па тым жа прынцыпе. Наладзьце кліент на гэты існуючы HTTP-пратакол і ўліковы запіс; перадача праз SSH не стварае SOCKS або HTTPS-слухач з TLS.
Існуючы сэрвіс па-ранейшаму выбірае падтрымліваемыя версіі пратаколу, аўтэнтыфікацыю, пункты прызначэння і канчатковы выхад. Калі іншы працэс SSH стварыў гэты аддалены проксі, абодва працэсы павінны заставацца жывымі. Маршрут ноўтбук→рэлей→шлюз пакідае сайт бачачым апошняе знешняе злучэнне, а не ідэнтычнасць, выдзеленую лакальным портам 1081.
Трымайце прывязку ноўтбука яўна лакальнай. Шырэйшае выкрыццё змяняе, хто можа дасягнуць сэрвісу, а ўваход праз SSH не дадае пароль SOCKS да слухача. Пры адмове правярайце слухач ноўтбука, транспарт SSH і аддалены проксі як асобныя этапы.