Вы мяркуеце, што 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 па прыладах ці рэсурсах; ужыты ўнутры іх, ён проста адзін дазволены шлях праграмы з яўнымі межамі.

Падобныя артыкулы