SSH ngec te SSH2_MSG_KEX_ECDH_REPLY: nuk është gjithmonë MTU

Tuneli është aktiv, baneri arrin dhe klienti shtyp një mesazh për pritjen e përgjigjes së shkëmbimit të çelësave. Rezultatet e kërkimit tregojnë drejt MTU-së, dhe ndonjëherë kjo është e saktë. Shpesh nuk është: përgjigja mund të mos jetë dërguar kurrë, sepse klienti nuk mundi të lexojë një skedar çelësi ose palët nuk u morën vesh kurrë për një algoritëm. Rreshti përshkruan atë që pret klienti, jo pse filloi pritja. Trajtojeni si simptomë dhe ndani tre shkaqet përpara se të ndryshoni çdo madhësi.

Lexoni gjurmën për të parë nëse pritej fare një përgjigje

Dalja e detajuar tregon hapin e fundit të suksesshëm përpara heshtjes. Nëse baneri i protokollit të serverit ka ardhur, TCP funksionon dhe skaji i largët është gjallë; pyetja e hapur është çfarë ndodhi me një paketë të caktuar. Një minutë heshtje pas banerit duket si problem rruge. Një mesazh për asnjë metodë shkëmbimi çelësash që përputhet është problem politike. Një pritje e gjatë që përfundon me mbylljen e sesionit nga serveri do të thotë se serveri u dorëzua, dhe regjistri i tij shpjegon pse.

Në rastin e fundit, lexoni regjistrin e autentikimit të serverit përpara se të prekni klientin. Klienti nuk mund të shohë një vendim që serveri nuk e dërgoi kurrë.

Pse një përgjigje e vogël mund të jetë ende shumë e madhe

Përgjigjet e shkëmbimit të çelësave zakonisht janë shumë të vogla, prandaj fajësimi i madhësisë tingëllon gabim. Me certifikata hosti përgjigja nuk është e vogël, sepse mban zinxhirin e certifikatave të serverit. Kjo e bën atë paketën e parë në sesion që mund të tejkalojë ngarkesën e përdorshme të tunelit. Kur reagimi i zbulimit të MTU-së së rrugës humbet diku në rrugë, dërguesi vazhdon të ridërgojë një paketë që nuk futet, dhe klienti pret përgjithmonë në të njëjtin rresht.

Përcaktoni madhësinë në vend që ta supozoni. Lexoni MTU-në e tunelit me ip link show tun0, pastaj dërgoni sonda që nuk duhet të fragmentohen: ping -4 -M do -s 1352 host, të përsëritura me ngarkesa më të vogla. Një ndryshim nga dështimi në sukses në një madhësi të caktuar është provë; dështimi uniform sugjeron se ICMP është filtruar dhe nuk ju thotë asgjë.

Një zvogëlim i përkohshëm e konfirmon teorinë shpejt, dhe një version i qëndrueshëm i përket profilit ose si një kufizim MSS në routerin që përcjell tunelin:

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

Dy shkaqet që imitojnë një problem madhësie

Një skedar çelësi që klienti nuk mund ta lexojë prodhon të njëjtën pritje, pa paralajmërim edhe në daljen e detajuar. Një model known_hosts e bën këtë të lehtë: një hyrje @cert-authority që tregon një çelës publik CA që vetëm një llogari mund ta lexojë. Llogaria që zotëron skedarin lidhet, dhe çdo llogari tjetër ngec. Nëse dështimi ndjek përdoruesin dhe jo hostin, kontrolloni mënyrat e skedarit përpara madhësive të paketave.

Një përditësim mund të heqë gjithashtu algoritmin që të dy skajet e ndanin më parë. Fiksoni një metodë që serveri ende ofron si diagnostikim: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Një lidhje që ka sukses menjëherë provon se rruga është në rregull dhe rregullimi i përket politikës së negociimit në të dyja anët.

Tre fakte që ia vlen të shënohen

Shënoni MTU-në e tunelit përpara dhe pas çdo ndryshimi, nëse kopjimi i një skedari të madh dështon në një madhësi të përsëritshme dhe nëse një host pa certifikatë në të njëjtin tunel ngec në të njëjtën mënyrë. Këto tre vëzhgime ndajnë madhësinë nga lejet dhe nga negociimi më shpejt se një grumbull komandash.

Ato gjithashtu parandalojnë personin tjetër të ulë MTU-në për një defekt që nuk kishte të bënte kurrë me madhësinë.

Nëse fotografia është ende e paqartë, provoni nga një klient i dytë në të njëjtin tunel. Një klient që lidhet e zhvendos defektin nga rruga në konfigurimin e makinës së parë.