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 робіць гэта лёгкім: запіс @cert-authority, які паказвае на публічны ключ CA, чытаць які можа толькі адзін уліковы запіс. Уліковы запіс, які валодае файлам, падключаецца, а ўсе іншыя завісаюць. Калі збой ідзе за карыстальнікам, а не за хастам, праверце рэжымы файла перад памерамі пакетаў.

Абнаўленне таксама можа выдаліць алгарытм, які абодва бакі раней падзялялі. Замацуйце адзін метад, які сервер яшчэ прапаноўвае, як дыягностыку: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Злучэнне, якое адразу атрымліваецца, даказвае, што шлях у парадку, і выпраўленне належыць палітыцы перамоваў з абодвух бакоў.

Тры факты, якія варта запісаць

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

Яны таксама не даюць наступнаму чалавеку знізіць MTU праз дэфект, які ніколі не быў звязаны з памерам.

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