Göngin eru uppi, bannerið kemur og biðlarinn prentar skilaboð um að bíða eftir svari lyklaskiptanna. Leitarniðurstöður benda beint á MTU, og stundum er það rétt. Oft er það ekki: svarið kann að hafa aldrei verið sent, vegna þess að biðlarinn gat ekki lesið lykilskrá eða endarnir urðu aldrei sammála um reiknirit. Línan lýsir því sem biðlarinn bíður eftir, ekki hvers vegna biðin hófst. Meðhöndlaðu hana sem einkenni og aðgreindu þrjár orsakirnar áður en þú breytir einhverri stærð.

Lestu slóðina til að sjá hvort svars var yfirhöfuð vænst

Ítarleg úttak sýnir síðasta vel heppnaða skrefið fyrir þögnina. Ef bókstaflegt banner netþjónsins er komið er TCP í lagi og fjær endinn lifandi; opin spurning er hvað varð um eitt tiltekið pakka. Ein mínúta af þögn eftir bannerið lítur út eins og vandamál í leið. Skilaboð um að engin samsvarandi lyklaskiptaaðferð sé til eru stefnumál. Löng bið sem endar með því að netþjónninn lokar lotunni þýðir að netþjónninn gafst upp, og skráin hans útskýrir hvers vegna.

Í síðasta tilvikinu skaltu lesa auðkenningarskrá netþjónsins áður en þú snertir biðlarann. Biðlarinn getur ekki séð ákvörðun sem netþjónninn sendi aldrei.

Hvers vegna lítið svar getur samt verið of stórt

Svör við lyklaskiptum eru venjulega örsmá, svo það hljómar rangt að kenna stærðinni. Með hýsilvottorðum er svarið ekki örsmátt, því það ber vottorðakeðju netþjónsins. Það gerir það að fyrsta pakkanum í lotunni sem getur farið yfir nothæfa hleðslu ganganna. Þegar endurgjöf vegar-MTU uppgötvunar tapast einhvers staðar á leiðinni heldur sendandinn áfram að endursenda pakka sem kemst ekki fyrir, og biðlarinn bíður að eilífu á sömu línu.

Ákvarðaðu stærðina í stað þess að gera ráð fyrir henni. Lestu MTU ganganna með ip link show tun0, sendu síðan prófanir sem mega ekki sundrast: ping -4 -M do -s 1352 host, endurteknar með minni hleðslum. Breyting frá mistökum til árangurs við tiltekna stærð er sönnun; samræmd mistök benda til að ICMP sé síað og segja þér ekkert.

Tímabundin lækkun staðfestir kenninguna fljótt, og varanleg útgáfa á heima í sniðinu eða sem MSS-þrenging á beininum sem sendir göngin áfram:

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

Tvær orsakirnar sem líkja eftir stærðarvanda

Lykilskrá sem biðlarinn getur ekki lesið framkallar sömu bið, án viðvörunar jafnvel í ítarlegu úttaki. Eitt known_hosts mynstur gerir þetta auðvelt: @cert-authority færsla sem bendir á opinberan CA-lykil sem aðeins eitt notandareikningur getur lesið. Reikningurinn sem á skrána tengist, og hver annar reikningur stendur. Ef bilunin fylgir notandanum en ekki hýslinum skaltu athuga skráarhami áður en þú skoðar pakkastærðir.

Uppfærsla getur líka fjarlægt reikniritið sem báðir endar deildu áður. Festu eina aðferð sem netþjónninn býður enn sem greiningu: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Tenging sem tekst strax sannar að leiðin sé í lagi og að lagfæringin eigi heima í samningastefnu beggja aðila.

Þrjár staðreyndir sem er þess virði að skrifa niður

Skrifaðu niður MTU ganganna fyrir og eftir hverja breytingu, hvort afritun stórrar skráar mistekst við endurtekna stærð og hvort hýsill án vottorðs í sömu göngum stendur á sama hátt. Þessar þrjár athuganir aðgreina stærð frá heimildum og frá samningum hraðar en stafli af skipunum.

Þær koma líka í veg fyrir að næsta manneskja lækki MTU vegna bilunar sem snerist aldrei um stærð.

Ef myndin er enn óljós skaltu prófa frá öðrum biðlara í sömu göngum. Biðlari sem tengist færir bilunina frá leiðinni yfir í stillingar fyrstu vélarinnar.

Tengdir greinar