Дынамічнае перанакіраванне SSH як SOCKS-проксі праз ваш VPN
Праграма, якая разумее толькі SOCKS, не мае кропкі проксі ў звычайным VPN. Два пераходы, адзін лакальны слухач і пошук імені, які павінен зрабіць сам сервер SSH.
Праграма, якая разумее толькі SOCKS, не мае з чым размаўляць у звычайным VPN, бо тунель пераносіць пакеты, а праграме патрэбна кропка проксі. OpenSSH можа даць гэтую кропку, калі ўладальнік доступу дазваляе, бо дынамічнае перанакіраванне ператварае адну сесію SSH у лакальны проксі. Далей ёсць два пераходы, якія трэба трымаць паасобку: тунель, што дасягае хоста SSH, і злучэнне, якое гэты хост адкрывае далей. Іх раздзяленне тлумачыць і тое, чаму схема працуе, і тое, чаго яна ніколі не зробіць.
Чым слухач SSH становіцца, а чым не
Дынамічнае перанакіраванне прымушае кліент SSH слухаць лакальна і гаварыць SOCKS4 або SOCKS5 з усім, што падключаецца. Кожны запыт называе пункт прызначэння, і сервер SSH адкрывае далейшае злучэнне, таму пошук пункта прызначэння можа адбывацца на далёкім баку. Гэта перанакіраванне TCP на ўзроўні праграмы, а не VPN для ўсёй прылады. Яно не нясе ні асацыяцыі UDP, ні ICMP, ні чаго-небудзь для праграм, якія цалкам ігнаруюць налады проксі. Пераход ад сервера SSH да праграмы таксама не ўнутры вашага тунеля, што важна, калі пункт прызначэння прымае трафік толькі з вядомых сетак.
Папярэднія ўмовы рэальныя: маршрут да хоста SSH, аўтарызаваны ўліковы запіс, правераны ключ хоста сервера і дазвол на перанакіраванне. Ніводную з іх не стварае проксі, і апошняя звычайна адсутнічае першай. Пацвердзіце ўсе чатыры, перш чым што-небудзь іншае, бо збоі выглядаюць аднолькава з кліента, якая б з іх ні была адсутная.
Запусціце яго на loopback з яўным портам
Выберыце вольны лакальны порт і прывяжыце яго яўна да loopback, а не пакідайце адрас пустым. Тры параметры ніжэй існуюць кожны па сваёй прычыне.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N прапускае аддаленую каманду, а -T прапускае псеўдатэрмінал, так што сесія існуе толькі для перанакіравання. ExitOnForwardFailure прымушае кліент выйсці, калі слухач не можа быць створаны, замест працы без запытанага перанакіравання. ControlPath=none трымае сесію па-за існуючым мультыплексаваным злучэннем, якое магло б дадаць свае перанакіраванні. Loopback трымае слухач па-за LAN, але на агульнай машыне гэта не мяжа аўтарызацыі, бо іншыя лакальныя працэсы таксама могуць да яго дабрацца. Даведка кліента OpenSSH апісвае ўсе гэтыя параметры, і папярэджанне пра loopback вынікае з таго, чым з’яўляецца слухаючы сокет.
Праводзьце імёны праз проксі, а не вакол яго
Кліент SOCKS5 можа сам вырашыць пункт прызначэння або папрасіць гэта зрабіць проксі, і гэты выбар вызначае, які рэзалвер адкажа. З socks5h curl перадае імя хоста праз проксі, таму пошук адбываецца на серверы SSH. З простым socks5 ноўтбук спачатку вырашае сам, і падарожнічае толькі злучэнне, што ціха знішчае сэнс, калі імя ўнутранае. Запыт ніжэй таксама ачышчае спіс без проксі, каб унаследаванае значэнне NO_PROXY не магло накіраваць яго вакол проксі.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthПраверка сертыфіката і ўласны ўваход праграмы па-ранейшаму дзейнічаюць, бо проксі не замяняе ні таго, ні таго. Застаюцца два пошукі: ноўтбук павінен дасягнуць хоста SSH праз дазволены шлях VPN і DNS, а сервер SSH павінен сам вырашыць імя праграмы. Другі можна праверыць асобна, перш чым любы трафік пойдзе праз проксі.
ssh [email protected] getent hosts app.corp.exampleДакажыце адзін дазволены пункт прызначэння, потым зачыніце сесію
Праверце пункт прызначэння, які дазваляе палітыка, і той, які яна павінна адхіліць, бо працоўнае перанакіраванне даказвае толькі тое, што слухач працуе, і больш нічога. Праграма бачыць адрас крыніцы, які выбірае сервер SSH, а гэта не адрас тунеля вашага ноўтбука. Калі далёкі бок запісвае злучэнні па крыніцы, менавіта гэта розніца — першае, што варта праверыць, калі запыт адхілены.
Спыніце сесію праз працэс, які ёю валодае, а не забіваючы староннюю абалонку. Потым пераканайцеся, што слухач знік, бо порт, які ўсё яшчэ адказвае, — гэта сесія, якую вы насамрэч не зачынілі. Выдаліце толькі наладу проксі, якую ўвяло гэтае практыкаванне, і пакіньце астатнюю канфігурацыю праграмы ў спакоі. Тэрмінал без нагляду з правілам перанакіравання — не служба, і пастаянны проксі патрабуе ўзгодненага жыццёвага цыкла, а не забытага акна.
ss -ltn | grep 1080Збоі, якія гэтая схема не можа выправіць
Некаторыя сімптомы ўказваюць прама на абмежаванні вышэй, і ранняе іх распазнанне зэканоміць паўдня на адладцы проксі. Табліца суадносіць тое, што вы бачыце, з тым, што гэта звычайна значыць. Усё ў апошнім слупку — пытанне праектавання, а не памылка канфігурацыі.
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
Першыя тры радкі — гэта тыя, якія людзі дыягнастуюць няправільна, бо кожны дае спробу злучэння, а не памылку пра сам проксі. Імя, якое вырашаецца на ноўтбуку, нічога не кажа пра рэзалвер сервера, і збой чытаецца як праблема сертыфіката або тайм-аўту. Праграмы толькі з UDP стаяць па-за межамі схемы, а не зламаныя ўнутры яе, і ніякі дадатковы параметр ssh гэтага не зменіць. Радок пра браўзер — звычайнае напамінанне, што налады проксі дзейнічаюць для кожнай праграмы асобна. Апошні радок — прычына існавання праверкі закрыцця: порт, які ўсё яшчэ слухае, азначае, што цяпер ім валодае нешта іншае.