Доступ да HTTPS-сайта толькі праз VPN з дапамогай SSH-перанакіравання

На адной машыне ўжо ёсць ухвалены доступ да VPN, другой машыне патрэбна роўна адна прыватная HTTPS-служба, і лакальнае SSH-перанакіраванне можа закрыць гэтую прагаліну, не даючы другой машыне тунель. Перанакіраванне нясе адзін TCP-адрас замест усёй сеткі, і менавіта гэтае абмежаванне і ёсць сутнасцю. Прайдзіце пяць крокаў ніжэй па парадку, бо кожны з іх правальваецца з іншай прычыны, і наступны крок не выратуе папярэднюю прагаліну. Калі нейкая перадумова адсутнічае, гэтая схема яе не вырашае, і ніякая наладка каманд не дапаможа.

Крок першы: пацвердзіце тры перадумовы

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

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

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Крок другі: прывяжыце порт loopback і трымайце сеанс жывым

На машыне, дзе працуе кліенцкая праграма, адкрыйце лакальнае перанакіраванне да прыватнай службы. Прывяжыце яго яўна да loopback, каб яно не публікавалася ў лакальнай сетцы, і выберыце высокі порт, які не заняты ніякай лакальнай службай. Трымайце сеанс адкрытым, пакуль працуеце, бо яго закрыццё закрывае слухача. ExitOnForwardFailure ператварае адмоўленае прывязванне або заняты порт у неадкладны выхад замест сеансу, які застаецца ўзнятым без перанакіравання, і менавіта гэты рэжым адмовы марнуе найбольш часу.

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Крок трэці: захавайце імя HTTPS, калі сокет лакальны

Пераход на https://127.0.0.1:9443/ змяняе імя сервера TLS і паўнамоцтвы праграмы. Сертыфікат, выдадзены для portal.lab.example, не будзе правярацца супраць адраса loopback, і ўзніклая памылка выглядае як зламаны сертыфікат, а не як скарочаны шлях перанакіравання. Для тэсту з каманднага радка захавайце сапраўдны URL і змяніце толькі прызначэнне сокета. Гэта робіць --connect-to, і дапаможнік curl апісвае чатырохпалёвую форму, выкарыстаную ніжэй.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Імя застаецца ў URL, у рукапацісканні TLS і ў загалоўку Host, а TCP-злучэнне ідзе да лакальнага слухача. Параметр без проксі трымае тэст на гэтым перанакіраванні, замест таго каб наладжаны HTTP-проксі перахапіў яго, а захаванне праверкі сертыфіката робіць вынік значным.

Крок чацвёрты: ведайце, што не пакрывае адно перанакіраванне

Адно TCP-перанакіраванне пакрывае адзін порт прызначэння. Старонка, якая перанакіроўвае на другое імя хоста, загружае рэсурсы з хоста ўнутры прыватнай сеткі або адпраўляе даныя на іншы порт, патрабуе ўласнага перанакіравання, і кожнае з іх патрабуе такой жа праверкі палітыкі, як першае. Працэсы ў браўзеры дадаюць свае патрабаванні, бо браўзеру трэба сказаць адпраўляць сапраўднае імя на лакальны порт праз канфігурацыю проксі або лакальнае супастаўленне. Таму паспяховы тэст з каманднага радка не даказвае, што браўзер справіцца, хоць і даказвае шлях.

UDP, выяўленне SMB і ўваход у дамен зусім не ідуць праз TCP-перанакіраванне. Калі сапраўдная патрэба — агульны доступ да сеткі, гэтая схема — няправільны інструмент, а правільны — падтрыманы шлюз аддаленага доступу.

Крок пяты: прыбярыце і запішыце

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

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