Дайце аддаленаму Pi SOCKS-проксі праз ваш SSH-кліент
Аддаленае дынамічнае пракіданне змяшчае слухач SOCKS на Pi і робіць далейшае злучэнне з зацверджанага VPN-шляху вашага ноўтбука. Другі SSH-сервер не патрэбны.
Вы мяркуеце, што SOCKS-проксі павінен працаваць там, дзе ўжо ёсць доступ у сетку. OpenSSH можа размясціць слухача зусім у іншым месцы. Аддаленае дынамічнае пракіданне адкрывае порт SOCKS на аддаленым хосце і пачынае кожнае злучэнне з вашага лакальнага SSH-кліента, які нясе зацверджаны VPN-шлях вашага ноўтбука. Pi атрымлівае абмежаваны проксі; ён не наследуе ваш тунель і вашы прывілеі.
Слухач і бок, адкуль ідзе злучэнне, могуць адрознівацца
Звычайны ssh -D 1080 запускае слухача на вашай уласнай машыне і адпраўляе злучэнні адтуль. Аддаленае дынамічнае пракіданне робіць наадварот: слухач з'яўляецца на аддаленым хосце, і кожнае злучэнне, якое ён прымае, адкрываецца з лакальнага боку. Кіраўніцтва кліента OpenSSH апісвае -R без фіксаванага прызначэння менавіта як такую схему SOCKS4/5.
Падтрыманая каманда з ноўтбука выглядае так, дзе ўліковы запіс, хасты і порт — гэта запаўняльнікі:
ssh -NT -S none -o ExitOnForwardFailure=yes \
-o PermitRemoteOpen=app.corp.example:443 \
-R 1080 [email protected]
Тры дэталі робяць там карысную працу. -S none трымае сеанс далей ад агульнага кантрольнага майстра, ExitOnForwardFailure хутка спыняецца замест таго, каб пакінуць вас з паўадкрытым сеансам, а PermitRemoteOpen абмяжоўвае, да чаго можа дабрацца аддалены слухач. Выкарыстоўвайце аўтарызаваны ўліковы запіс Pi і перад любым з гэтага праверце ключ хоста.
Што насамрэч адкрывае аддалены слухач
Праверце палітыку пракідання сервера, перш чым спадзявацца на слухача. З GatewayPorts no аддаленае пракіданне застаецца прывязаным да loopback, і гэта менавіта тое ўздзеянне, якое вам патрэбна. Сервер, настроены на прымусовае пракіданне з падстаноўнымі знакамі, публікуе той жа порт на ўсіх інтэрфейсах, і гэта ператварае асабісты проксі ў нешта дасягальнае для лакальнай сеткі.
Loopback таксама не з'яўляецца мяжой паміж карыстальнікамі. Іншы працэс на Pi можа падключыцца да 127.0.0.1:1080, калі ведае порт, таму лакальныя ўліковыя запісы Pi і ўсё, што на ім працуе, — частка вашай схемы доступу. Гэта прычына трымаць спіс прызначэнняў вузкім, а не прычына прапусціць праверку палітыкі.
Трымайце дазволенае прызначэнне канкрэтным для праграмы, да якой імкніцеся. Замена яго неабмежаваным пракіданнем, каб запрацавала старонняя праграма, пашырае шлях значна далей за праблему, з якой вы пачалі. Спіс прызначэнняў таксама фіксуе, для чаго быў сеанс, і гэта дапамагае таму, хто будзе правяраць яго пазней. Запішыце яго побач з уліковым запісам, які вы выкарыстоўвалі.
Правядзіце адну праграму праз проксі
Кліент на Pi, які разумее проксі, тады можа зрабіць запыт. Прэфікс socks5h перадае імя прызначэння проксі, таму пошук і злучэнне адбываюцца на баку ноўтбука, і гэта адпавядае названаму прызначэнню ў PermitRemoteOpen:
curl --proxy socks5h://127.0.0.1:1080 \
--noproxy '' https://app.corp.example/
Захавайце звычайную праверку сертыфіката і ўласную аўтэнтыфікацыю праграмы. Проксі змяняе месца, дзе ўсталёўваецца TCP-злучэнне; ён не робіць неаўтэнтыфікаваны сэрвіс бяспечным і не ператварае самападпісаны пункт у давераны.
Ноўтбуку па-ранейшаму патрэбны свой маршрут і доступ да рэзалвера як да SSH-сервера, так і да праграмы. Трафік яго SSH-кліента павінен выбірацца зацверджанай палітыкай VPN, а выключэнне split-tunnel можа адправіць гэты трафік іншым шляхам, чым той, які вы правяралі.
Дакажыце шлях і зачыніце яго
Пераканайцеся, што слухач існуе там, дзе вы чакаеце, і што адказвае толькі прызначанае прызначэнне:
$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
--proxy socks5h://127.0.0.1:1080 https://app.corp.example/
ExitOnForwardFailure можа даказаць, што пракіданне ўсталяванае, і ўсё роўна не можа пацвердзіць, што ўваход у праграму ўдаецца ніжэй па плыні. Тэстуйце праграму, а не толькі порт. Слухач, які прымае, а потым правальвае кожны запыт, звычайна азначае, што імя прызначэння або маршрут ноўтбука няправільныя, а не што тунель не спрацаваў.
Гэтая схема нясе толькі TCP. UDP, ICMP і праграмы, якія ігнаруюць налады проксі, застаюцца па-за ёй, а пракіданне сканчаецца ў той момант, калі сканчаецца SSH-сеанс. Спыніце гэты сеанс, калі скончыце, і выдаліце наладу проксі, якую вы дадалі ў праграму.
Для пастаяннага доступу выкарыстоўвайце замест гэтага падтрыманую рэгістрацыю ўладальніка сеткі або кіраваны шлюз. Зваротны проксі — няправільны інструмент для абыходу абмежаванняў VPN па прыладах ці рэсурсах; ужыты ўнутры іх, ён проста адзін дазволены шлях праграмы з яўнымі межамі.