Лакальная перасылка SSH да наяўнага HTTP-проксі: два loopback-адрасы

Ваш зацверджаны проксі працуе на прамежкавым хосце, дзе ён слухае толькі на loopback, таму нішто па-за гэтай машынай не можа да яго дабрацца. Вам не патрэбны VPN або новы проксі; вам патрэбны адзін порт гэтай машыны, перанесены на адзін ваш порт. Лакальная перасылка робіць менавіта гэта, і для яе патрэбны адзін загад і адна налада праграмы. Блытаніна звычайна ўзнікае з-за змешвання таго, які loopback-адрас належыць якой машыне.

Вызначце, ці ўжо ёсць фіксаваны проксі

Гэтая тэхніка перасылае службу, якая ўжо працуе. Калі на аддаленым хосце ёсць толькі дэман SSH і няма проксі, ніякая колькасць перасылак яго не створыць, і злучэнне будзе адхілена з аддаленага боку. Пераканайцеся, што проксі прывязаны, што вядомы яго порт і ці слухае ён на 127.0.0.1 або на пэўным адрасе інтэрфейса, бо менавіта гэты адрас павінна мэтаваць перасылка.

Калі праверыць гэта адразу, вам не давядзецца адладжваць тунель, які ніколі ні да чаго не падключаўся.

Пабудуйце перасылку і прачытайце загад

Патрэбная форма прывязвае порт loopback на вашым ноўтбуку і злучае яго з боку сервера з адрасам проксі так, як сервер яго бачыць.

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

Ключ -N выключае аддалены загад, а -T выключае выдзяленне termios, бо вам патрэбны тунель, а не абалонка. Першы loopback-адрас — гэта месца, дзе слухае ноўтбук; другі вызначаецца серверам SSH, таму 127.0.0.1 там азначае проксі на гэтай машыне. ExitOnForwardFailure прымушае загад гучна збаўляцца, калі лакальны порт ужо заняты, замест таго каб пачаць сеанс, які нічога не перасылае. Запісвайце адрас прызначэння так, як яго вызначае сервер, бо імя, якое можа вызначыць толькі ваш ноўтбук, не спрацуе на тым баку.

Уласная палітыка сервера дзейнічае да таго, як хоць штосьці з гэтага запрацуе. AllowTcpForwarding павінен дазволіць гэта, а PermitOpen можа абмежаваць, да якіх прызначэнняў і партоў можа дабрацца сеанс, таму перасылку, якую кліент прымае, сервер усё яшчэ можа адхіліць. Адмова выглядае як памылка перасылкі або канала на кліенце, і чытанне гэтага паведамлення хутчэйшае за рэдагаванне загаду.

Направіце адну праграму на перасылку

Наладзьце праграму на выкарыстанне HTTP-проксі па http://127.0.0.1:13128, з уліковымі данымі, калі аддалены проксі іх патрабуе. Захавайце ўласную праверку сертыфікатаў праграмы для прызначэнняў HTTPS, бо тунель проксі яе не замяняе. Гэта фіксаваная перасылка адной службы, таму праграме трэба паведаміць пра проксі, а не пакідаць яе шукаць яго самастойна.

Хуткая праверка перад любой пастаяннай наладай: curl -x http://127.0.0.1:13128 -I https://example.com, што правярае метад HTTP CONNECT, які павінен падтрымліваць проксі.

Пакіньце паўнамоцтвы там, дзе яны былі

Аддалены проксі ўсё яшчэ вырашае, якія прызначэнні і метады ён дазваляе, і ўваход па SSH не павінен моўчкі даваць кожнаму ўліковаму запісу агульны вэб-рэлей. Прывязак да 127.0.0.1 на ноўтбуку пазбягае публікацыі порта ў вашу лакальную сетку, і ён не робіць порт прыватным ад іншых працэсаў на той жа машыне. Замена гэтай прывязкі адрасам wildcard, каб дзяліцца проксі, — так і ствараецца некіраваны адкрыты рэлей.

Транспарт SSH абараняе пераход да сервера. Далей проксі адкрывае ўласнае злучэнне, таму звычайны запыт HTTP да прызначэння застаецца звычайным пасля сервера, нават калі першы ўчастак быў зашыфраваны.

Праверце абодва бакі, потым прыбярыце

Наладжванне лакальнага тунеля і поспех аддаленай службы — розныя вынікі, і код выхаду загаду паведамляе толькі пра першы. Праверце, што слухач існуе, з дапамогай ss -ltn, потым зрабіце дазволены запыт праграмы і запыт, які проксі павінен адхіліць. Калі абодва паводзяць сябе як чакалася, шлях сапраўдны; калі тунель працуе, а кожны запыт збаўляецца, проксі адмаўляе або не можа дабрацца да прызначэння.

Калі скончыце, спыніце працэс SSH, які валодае тунелем, выдаліце наладу проксі з праграмы і пераканайцеся, што лакальны порт знік, а не пакінулі слухача, які перажыве задачу.