SSH iesprūst pie SSH2_MSG_KEX_ECDH_REPLY: tas ne vienmēr ir MTU

Tunelis ir aktīvs, baneris pienāk, un klients izdrukā ziņojumu par gaidīšanu uz atslēgu apmaiņas atbildi. Meklēšanas rezultāti norāda tieši uz MTU, un dažreiz tas ir pareizi. Bieži nav: atbilde varēja tikt nekad nosūtīta, jo klients nevarēja nolasīt atslēgas failu vai puses nekad vienojās par algoritmu. Rinda apraksta, ko klients gaida, nevis kāpēc gaidīšana sākās. Uztveriet to kā simptomu un atšķiriet trīs cēloņus pirms jebkura izmēra maiņas.

Izlasiiet pēdas, lai redzētu, vai atbilde vispār tika gaidīta

Detalizētā izvade parāda pēdējo veiksmīgo soli pirms klusuma. Ja servera protokola baneris ir pienācis, TCP darbojas un attālais gals ir dzīvs; atklātais jautājums ir, kas notika ar vienu konkrētu paketi. Minūte klusuma pēc banera izskatās kā ceļa problēma. Ziņojums par to, ka nav atbilstošas atslēgu apmaiņas metodes, ir politikas problēma. Ilga gaidīšana, kas beidzas ar servera sesijas aizvēršanu, nozīmē, ka serveris padevās, un tā žurnāls izskaidro kāpēc.

Pēdējā gadījumā izlasiiet servera autentifikācijas žurnālu pirms klienta aizskaršanas. Klients nevar redzēt lēmumu, ko serveris nekad nebija nosūtījis.

Kāpēc maza atbilde tomēr var būt pārāk liela

Atslēgu apmaiņas atbildes parasti ir sīkas, tāpēc izmēra vainošana izklausās nepareizi. Ar resursdatora sertifikātiem atbilde nav sīka, jo tā nes servera sertifikātu ķēdi. Tas to padara par pirmo sesijas paketi, kas var pārsniegt tuneļa izmantojamo kravu. Kad ceļa MTU noteikšanas atgriezeniskā saite kaut kur maršrutā tiek pazaudēta, sūtītājs pastāvīgi atkārtoti sūta paketi, kas neietilpst, un klients mūžīgi gaida tajā pašā rindā.

Nosakiet izmēru, nevis pieņemiet to. Nolasiet tuneļa MTU ar ip link show tun0, pēc tam sūtiet zondes, kuras nedrīkst fragmentēt: ping -4 -M do -s 1352 host, atkārtojiet ar mazākām kravām. Pāreja no neveiksmes uz panākumiem noteiktā izmērā ir pierādījums; vienveidīga neveiksme liek domāt, ka ICMP tiek filtrēts, un neko jums nepasaka.

Īslaicīga samazināšana ātri apstiprina teoriju, un ilgtermiņa versija pieder profilam vai MSS ierobežojumam maršrutētājā, kas pārsūta tuneli:

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

Divi cēloņi, kas atdarina izmēra problēmu

Atslēgas fails, ko klients nevar nolasīt, rada tādu pašu gaidīšanu, bez brīdinājuma pat detalizētā izvadē. Viens known_hosts šablons to atvieglo: @cert-authority ieraksts, kas norāda uz CA publisko atslēgu, ko var nolasīt tikai viens konts. Konts, kuram pieder fails, izveido savienojumu, un katrs cits konts iesprūst. Ja kļūme seko lietotājam, nevis resursdatoram, pārbaudiet faila režīmus pirms paketes izmēriem.

Atjauninājums var arī noņemt algoritmu, ko abi gali iepriekš kopīgoja. Fiksējiet vienu metodi, ko serveris joprojām piedāvā, kā diagnostiku: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Savienojums, kas uzreiz izdodas, pierāda, ka ceļš ir kārtībā un labojums pieder abu pušu sarunu politikai.

Trīs fakti, ko ir vērts pierakstīt

Pierakstiet tuneļa MTU pirms un pēc jebkuras izmaiņas, vai liela faila kopēšana neizdodas atkārtojamā izmērā un vai resursdators bez sertifikāta tajā pašā tunelī iesprūst tāpat. Šie trīs novērojumi atdala izmēru no atļaujām un no sarunām ātrāk nekā komandu kaudze.

Tie arī neļauj nākamajam cilvēkam samazināt MTU kļūmes dēļ, kas nekad nebija saistīta ar izmēru.

Ja aina joprojām nav skaidra, pārbaudiet no otra klienta tajā pašā tunelī. Klients, kas izveido savienojumu, pārceļ kļūmi no ceļa uz pirmās mašīnas konfigurāciju.