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-г буулгахыг саатуулдаг.

Хэрэв зураг одоо ч тодорхойгүй бол мөн туннелийн хоёр дахь клиентээс туршиж үзээрэй. Холбогдсон клиент алдааг замаас эхний машины тохиргоо руу шилжүүлдэг.