SSH SSH2_MSG_KEX_ECDH_REPLY кезеңінде ілінеді: себеп әрдайым MTU емес

Туннель қосулы, баннер келеді және клиент кілт алмасу жауабын күтіп жатқаны туралы хабарлама шығарады. Іздеу нәтижелері тікелей MTU-ға нұсқайды, кейде бұл дұрыс. Көбінесе олай емес: жауап мүлде жіберілмеген болуы мүмкін, себебі клиент кілт файлын оқи алмады немесе тараптар алгоритм туралы келісе алмады. Жол клиенттің нені күтіп тұрғанын сипаттайды, күтудің неден басталғанын емес. Оны симптом ретінде қабылдап, кез келген өлшемді өзгертуден бұрын үш себепті бөліңіз.

Жауаптың жалпы күтілгенін көру үшін ізді оқыңыз

Егжей-тегжейлі шығыс үнсіздік алдындағы соңғы сәтті қадамды көрсетеді. Сервердің протокол баннері келсе, TCP жұмыс істеп тұр және алыс жақ тірі; ашық сұрақ — бір нақты пакетке не болғаны. Баннерден кейінгі бір минут үнсіздік жол мәселесіне ұқсайды. Сәйкес кілт алмасу әдісі жоқтығы туралы хабарлама саясат мәселесі. Сервер сессияны жабуымен аяқталатын ұзақ күту сервер бас тартқанын білдіреді, ал оның журналы себебін түсіндіреді.

Соңғы жағдайда клиентке тиер алдында сервердің аутентификация журналын оқыңыз. Клиент сервер ешқашан жібермеген шешімді көре алмайды.

Неге кішкентай жауап әлі де тым үлкен болуы мүмкін

Кілт алмасу жауаптары әдетте өте кішкентай, сондықтан өлшемді кінәлау дұрыс емес естіледі. Хост сертификаттарымен жауап кішкентай емес, өйткені ол сервердің сертификаттар тізбегін тасымалдайды. Бұл оны сессиядағы туннельдің пайдалы жүктемесінен асуы мүмкін бірінші пакет етеді. Жол MTU-ын анықтау кері байланысы маршруттың бір жерінде жоғалса, жіберуші сыймайтын пакетті қайта-қайта жібере береді, ал клиент сол жолда мәңгі күтеді.

Өлшемді болжаудың орнына анықтаңыз. Туннельдің MTU-ын ip link show tun0 арқылы оқыңыз, содан кейін бөлшектелмеуі тиіс сынақтар жіберіңіз: ping -4 -M do -s 1352 host, кішірек жүктемелермен қайталаңыз. Белгілі бір өлшемде сәтсіздіктен сәттілікке ауысу дәлел; біркелкі сәтсіздік ICMP сүзіліп жатқанын көрсетеді және сізге ештеңе айтпайды.

Уақытша төмендету теорияны тез растайды, ал тұрақты нұсқа профильде немесе туннельді өткізетін маршрутизатордағы MSS шектеуі ретінде тұрады:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Өлшем мәселесіне еліктейтін екі себеп

Клиент оқи алмайтын кілт файлы дәл сол күтуді тудырады, егжей-тегжейлі шығыста да ескертусіз. known_hosts-тың бір үлгісі мұны жеңілдетеді: тек бір тіркелгі оқи алатын CA ашық кілтіне нұсқайтын @cert-authority жазбасы. Файлға ие тіркелгі қосылады, ал қалған барлық тіркелгі ілінеді. Егер ақау хостты емес, пайдаланушыны қуып жүрсе, пакет өлшемдерінен бұрын файл режимдерін тексеріңіз.

Жаңарту екі жақ бұрын бөліскен алгоритмді де жоюы мүмкін. Сервер әлі ұсынатын бір әдісті диагностика ретінде бекітіңіз: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Бірден сәтті болған қосылым жолдың дұрыстығын дәлелдейді және түзету екі жақтың келіссөз саясатына жатады.

Жазып қоюға тұрарлық үш факт

Кез келген өзгеріс алдында және кейін туннельдің MTU-ын, үлкен файл көшіру қайталанатын өлшемде сәтсіз бола ма, және сол туннельдегі сертификатсыз хост дәл солай іліне ме, соны жазып қойыңыз. Осы үш байқау өлшемді рұқсаттардан және келіссөздерден бұйрықтар үйіндісінен гөрі тезірек бөледі.

Олар сондай-ақ келесі адамға ешқашан өлшемге қатысы болмаған ақау үшін MTU-ны төмендетуге жол бермейді.

Егер сурет әлі анық болмаса, сол туннельдегі екінші клиенттен сынап көріңіз. Қосылған клиент ақауды жолдан бірінші машинаның конфигурациясына ауыстырады.