NGINX ағындық релесі арқылы SSH-ды бұзбай өткізу

PROXY тақырыбы оны күтетін қабылдаушыға арналған хабарлама, ал проксиленген DNS жазбасы TCP релесі емес. Шеті мен жоғарғы ағынды бөлек түзетіңіз.

Реле арқылы қоғамдық SSH екі байланыссыз шекарада сәтсіздікке ұшырайды, ал біреуін түзету әдетте екіншісін ашады. Не шет ағынды тасымалдаудың орнына HTTP жауабын қайтарады, не реле алдына бэкенд оқуға ешқашан келіспеген тақырыпты қосады. Қайсысын көріп отырғаныңызды үш шарт анықтайды: қоғамдық жазба шын мәнінде нені нұсқайды, ағын блогы жоғарыға нені жібереді және SSH клиенті қандай атауды тексереді. Оларды осы ретпен өңдеңіз.

Екі шекара, екі белгі

Шеттегі ақау SSH баннері болуы тиіс жерге HTTP күй беті келгендей көрінеді. Қосылым 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 нұсқаулығы көрінбейді, өйткені қабылдаушы бұл протоколды білмейді, және бұл болмау — шешім, өткізіп жіберу емес.

Екі бағытты да бөлек қарастырыңыз. listen жолында proxy_protocol орнату NGINX өз клиентінің тақырыпты бірінші жіберуін күтетінін білдіреді; оны қарапайым SSH клиентіне қосу адамдар әдетте шешуге тырысатын мәселенің дәл керісін тудырады.

Қоғамдық хост атауы шын мәнінде қайда жетеді

SSH сессиясындағы HTTP 400 беті шет туралы дәлел. Жолдағы бір нәрсе 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 URL оны қарастырмайды, ал әдеттегі қашықтағы URL сіз шынымен дайындаған тасымалға сәйкес келуі керек.

Істеуге болмайтын нәрсе — ескерту жоғалуы үшін хост кілтін тексеруді өшіру. Бұл қайта бағыттау жөндеуі ешқашан тиюді сұрамаған қорғанысты алып тастайды және көрініс ыңғайсыздығын нақты әсер етуге айналдырады.

Әрбір секірісті бөлек тексеріңіз

Қоғамдық тыңдаушыны жеке сынаңыз, содан кейін реле хостынан реледен бэкендке қосылымды, тек содан кейін клиентті ұшынан ұшына сынаңыз. Осы үш сынақтың әрқайсысы басқа қабатты жоққа шығарады. Біреуін өткізіп жіберу қалған екі нәтижені түсіндіруге болмайтынын білдіреді. Үш байқау, ақау өмір сүре алатын үш орын.

Әр нәтижемен бірге межелік мекенжайды, портты және алғашқы протокол байттарын сақтаңыз. Бұл үштік шет қатесін VPN маршруттау мәселесінен және SSH аутентификация ақауынан ажыратады, және бұл жөндеу мен болжамның арасындағы айырмашылық.

Соңында, жоспарланған әсер етуді құжаттаңыз. SSH-ды жеке бэкендке тасымалдайтын TCP релесі қоғамдық периметрде әдейі ашылған тесік және кез келген басқа кіріс қызметі сияқты қарауды қажет етеді.

Қатысты мақалалар