SSH haltas ĉe SSH2_MSG_KEX_ECDH_REPLY: ne ĉiam temas pri MTU

La tunelo funkcias, la rubando alvenas, kaj la kliento presas mesaĝon pri atendo de la ŝlosilinterŝanĝa respondo. Serĉrezultoj montras rekte al MTU, kaj foje tio pravas. Ofte ne: la respondo eble neniam estis sendita, ĉar la kliento ne povis legi ŝlosildosieron aŭ la flankoj neniam interkonsentis pri algoritmo. La linio priskribas, kion la kliento atendas, ne kial la atendo komenciĝis. Traktu ĝin kiel simptomon kaj apartigu la tri kaŭzojn antaŭ ol ŝanĝi ajnan grandon.

Legu la spuron por vidi, ĉu respondo estis entute atendata

Detala eligo montras la lastan sukcesan paŝon antaŭ la silento. Se la protokola rubando de la servilo alvenis, TCP funkcias kaj la malproksima flanko vivas; la malfermita demando estas, kio okazis al unu difinita paketo. Unu minuto da silento post la rubando aspektas kiel voja problemo. Mesaĝo pri neniu kongrua ŝlosilinterŝanĝa metodo estas politika problemo. Longa atendo, kiu finiĝas per fermo de la sesio fare de la servilo, signifas, ke la servilo rezignis, kaj ĝia protokolo klarigas kial.

En la lasta kazo, legu la aŭtentikigan protokolon de la servilo antaŭ ol tuŝi la klienton. La kliento ne povas vidi decidon, kiun la servilo neniam sendis.

Kial malgranda respondo tamen povas esti tro granda

Respondoj de ŝlosilinterŝanĝo kutime estas etaj, do kulpigi la grandecon ŝajnas malĝuste. Kun gastigantaj atestiloj la respondo ne estas eta, ĉar ĝi portas la atestilan ĉenon de la servilo. Tio faras ĝin la unua paketo en la sesio, kiu povas superi la uzeblan ŝarĝon de la tunelo. Kiam la retrosciigo de malkovro de voja MTU perdiĝas ie sur la itinero, la sendanto daŭre resendas paketon, kiu ne povas eniri, kaj la kliento atendas eterne ĉe la sama linio.

Determinu la grandecon anstataŭ supozi ĝin. Legu la MTU de la tunelo per ip link show tun0, poste sendu provojn, kiuj ne rajtas fragmentiĝi: ping -4 -M do -s 1352 host, ripetitajn kun pli malgrandaj ŝarĝoj. Ŝanĝo de malsukceso al sukceso ĉe difinita grandeco estas pruvo; unuforma malsukceso sugestas, ke ICMP estas filtrita, kaj diras al vi nenion.

Provizora malpliigo rapide konfirmas la teorion, kaj daŭra versio apartenas al la profilo aŭ kiel MSS-limigilo sur la enkursigilo, kiu plusendas la tunelon:

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

La du kaŭzoj, kiuj imitas grandoproblemon

Ŝlosildosiero, kiun la kliento ne povas legi, produktas la saman atendon, sen averto eĉ en detala eligo. Unu ŝablono en known_hosts faciligas tion: enskribo @cert-authority, kiu montras al publika ŝlosilo de CA, kiun nur unu konto povas legi. La konto, kiu posedas la dosieron, konektiĝas, kaj ĉiu alia konto haltas. Se la malsukceso sekvas la uzanton anstataŭ la gastiganton, kontrolu dosierajn reĝimojn antaŭ pakegaj grandecoj.

Ĝisdatigo ankaŭ povas forigi la algoritmon, kiun ambaŭ flankoj antaŭe dividis. Fiksu unu metodon, kiun la servilo ankoraŭ proponas, kiel diagnozon: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Konekto, kiu tuj sukcesas, pruvas, ke la vojo estas en ordo kaj ke la korekto apartenas al la intertraktada politiko ambaŭflanke.

Tri faktoj indaj je notado

Notu la MTU de la tunelo antaŭ kaj post ajna ŝanĝo, ĉu kopiado de granda dosiero malsukcesas ĉe ripetebla grandeco kaj ĉu atestilolibre gastiganto en la sama tunelo haltas same. Tiuj tri observoj apartigas grandecon de permesoj kaj de intertraktado pli rapide ol stako da komandoj.

Ili ankaŭ malhelpas la sekvan personon malaltigi la MTU pro difekto, kiu neniam temis pri grandeco.

Se la bildo ankoraŭ ne klaras, testu de dua kliento en la sama tunelo. Kliento, kiu konektiĝas, movas la difekton de la vojo al la agordo de la unua maŝino.