SSH праз рэлей патоку NGINX без паломкі

Загаловак PROXY — гэта паведамленне для атрымальніка, які яго чакае, а праксіраваны запіс DNS не з'яўляецца рэлеем TCP. Выпраўляйце ўскрай і ўзыходны бок асобна.

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

Дзве межы, два сімптомы

Збой на ўскраі выглядае як HTTP-старонка стану, якая прыходзіць туды, дзе павінен быць банер SSH. Злучэнне завяршаецца на ўзроўні TCP, і першыя байты — гэта тэкст, які належыць вэб-серверу. Гэта неадпаведнасць пратаколаў, а не страчаны пакет. Гэта таксама кажа вам, што ўскрай наўмысна абслугоўвае для гэтага імя нешта іншае.

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

Гэтыя два лёгка зблытаць, бо абодва даюць кліент, які падключаецца і потым зрываецца. Менавіта першы атрыманы адказ пратакола адрознівае іх, таму ён і павінен трапіць у тыкет.

Загаловак PROXY — гэта паведамленне, а не перамыкач

У модулі патоку proxy_protocol on загадвае NGINX запісаць загаловак пратаколу PROXY у бок узыходнага боку перад карыснай нагрузкай. Ён не ўключае праксіраванне TCP і не мае ніякага дачынення да шыфравання SSH. Гэта запіска, адрасаваная атрымальніку. Калі атрымальнік не можа яе прачытаць, яна становіцца смеццем у пачатку патоку.

Служба-атрымальнік павінна спажываць гэты загаловак наўмысна. Звычайны sshd чакае абмен ідэнтыфікацыі SSH як першыя байты злучэння, таму нечаканая прэамбула ламае рукапаціск так, што гэта выглядае як пашкоджаны сервер.

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

Гэты фрагмент — усё, што патрэбна для працоўнага рэлея да бэкенда, дасяжнага праз VPN. Дырэктыва PROXY не з'яўляецца, бо атрымальнік не размаўляе на гэтым пратаколе, і гэтая адсутнасць — рашэнне, а не пропуск.

Таксама раздзяляйце два кірункі. Усталяванне proxy_protocol у радку listen азначае, што NGINX чакае, што яго ўласны кліент спачатку адправіць загаловак; уключэнне яго для звычайнага кліента SSH дае дакладна адваротнае ад праблемы, якую людзі звычайна спрабуюць вырашыць.

Што насамрэч дасягае публічнае імя хоста

Старонка HTTP 400 у сеансе SSH — гэта доказ пра ўскрай. Нешта ў шляху размаўляе на HTTP, і ніякая праца з ключом або ўліковым запісам на бэкендзе гэтага не зменіць. Спыніце змены бэкенда, пакуль ускрай не будзе вырашаны.

Звычайны праксіраваны запіс Cloudflare пераносіць свае падтрыманыя трафікі HTTP і HTTPS на вызначаных партах. Уключэнне праксі для імя хоста не стварае агульнага рэлея TCP, а перанос SSH на порт 443 не робіць яго HTTPS.

Існуюць два працаздольныя кірункі. Запіс толькі DNS можа паказваць на ваш уласны рэлей TCP, што пакідае рашэнне пра ўздзеянне ў вашых руках. Акрамя таго, выкарыстоўвайце прадукт, які відавочна дакументуе перадачу SSH, з уласнымі канфігурацыямі крыніцы, кліента і доступу.

Што б вы ні выбралі, рэлею ўсё яшчэ патрэбны маршрут VPN да бэкенда, дазволенае злучэнне і зваротны шлях. Маршрут не з'яўляецца неабавязковым, таму што публічны бок працуе.

Трымайце ідэнтычнасць SSH стабільнай праз псеўданім

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

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

Без HostKeyAlias OpenSSH шукае ключ хоста пад тым імем, да якога падключаецца, таму запіс перамяшчаецца, і кожны карыстальнік пры першым выкарыстанні бачыць папярэджанне пра зменены ключ. Усталяванне псеўданіма захоўвае запісы known-hosts стабільнымі, пакуль злучэнне па-ранейшаму ідзе праз рэлей.

Гэты псеўданім датычыцца толькі аддаленых рэпазітараў на аснове SSH. HTTPS-адрас Git да яго не звяртаецца, і тыповы адрас аддаленага рэпазітара павінен адпавядаць транспарту, які вы насамрэч забяспечылі.

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

Правярайце кожны крок асобна

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

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

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

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