Ping í VPN virkar en vefsíðan hangir: athugaðu stærðina

Bergmálssvör berast, fjartölvan virkar og vafrinn situr á auðri síðu þar til hann gefst upp. Tvær skýringar passa við þetta mynstur, og þær eru ekki afbrigði af einu vandamáli: stefna sem leyfði þjónustuna aldrei, eða pakkar sem hætta að komast fyrir þegar flutningurinn stækkar. Bergmálssvarið útilokar hvorugt.

Farðu frá minnstu spurningunni til þeirrar stærstu og skrifaðu niður hvað hvert skref sannaði í raun.

Bergmálssvar svarar miklu minni spurningu

Bergmálssvar segir að IP-stakk áfangastaðarins hafi svarað ICMP-beiðni frá upptökunni þinni. Það segir ekkert um hvort TCP-hlustari sé á þeirri gátt sem þú þarft, hvort stefna leyfi þá gátt eða hvort áfangastaðarhýsilinn síi umferð óháð gáttinni. Gátt sem leyfir eina þjónustu getur sleppt annarri á meðan bæði skotmörkin svara ping. Lestu svarið sem eina staðreynd um einn pakka og eina átt.

Staðfestu áfangastaðinn og gátt þjónustunnar áður en þú túlkar hvað annað sem er. Vistfangið sem þú prófaðir og vistfangið sem forritið notar eru stundum mismunandi færslur, og nafn sem leysist í tvö vistföng gerir það líklegt.

Finndu út hvort tengingin hófst

Tenging sem er hafnað samstundis er svar frá hlustaranum eða stefnunni: eitthvað svaraði og sagði nei. Tenging sem opnast og stöðvast svo þegar gögn fara að hreyfast bendir til stærðar. Tenging sem klárar aldrei handabandið er yfirleitt stefna eða leiðakerfi og lítur út eins og tímamörk frekar en höfnun.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Skrifaðu niður hvaða af þessum þremur þú sást áður en þú snertir MTU-stillingar. Að breyta stærð göngu til að laga hafnaða tengingu sóar breytingunni og felur raunverulega orsök í smástund.

Mældu stærð með uppgefinni tölu

Þegar stöðvunin birtist undir álagi, prófaðu eina pakkastærð með bannbitanum gegn sundurliðun stilltum og tilgreindu reikninginn svo niðurstaðan þýði eitthvað. Í Linux með iputils gefur 1392 bæta hleðsla auk 8 bæta ICMP-hauss og 20 bæta IPv4-hauss innri pakka sem er nákvæmlega 1420 bætur. Tilgreindu þennan reikning í málsmiðanum, því bert ping sem nær gáttinni sannar ekkert um forrit.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Báðar prófanirnar eru mælipunktar, ekki tillögur um stærð ganga. Ef ICMP er síað einhvers staðar á leiðinni segir tímamörk ekkert um stærð, því síun og of stór pakki líta eins út frá sjónarhóli biðlarans. Árangur segir líka ekkert um öfugáttina eða annan áfangastað.

Reiknaðu með ytri leiðinni

Innpökkun bætir við sínum eigin hausum, þannig að pakkinn á vírnum er stærri en pakkinn sem þú mældir inni í göngunni. Bilið á milli þeirra er það sem gerir virka litla beiðni og misheppnaða stóra mögulegar á sama tíma.

Uppgötvun leiðar-MTU í IPv4 byggist á endurgjöf um pakka sem ekki er hægt að senda áfram án sundurliðunar, og IPv6 notar Packet Too Big-skilaboð. IPv4-forskriftin lýsir þeirri aðferð. Að sía endurgjöfina eyðileggur hæfileika sendandans til að læra og lætur hann endursenda pakka sem munu aldrei komast fyrir. Þess vegna geta virk lítil beiðni og misheppnuð stór verið svo vel saman.

Breyttu einni tölu og prófaðu forritið aftur

Lækkaðu MTU ganganna eða takmarkaðu hámarksstærð íhluta fyrir TCP, endurtaktu síðan upprunalegu forritsprófunina í stað prófunarinnar. Prófun sem heppnast eftir breytinguna og forrit sem hangir enn er annað vandamál með svipaða lögun, og aðeins forritsprófunin greinir þau að.

Haltu reikningnum í breytingaskránni: mælda stærðin, álagið sem þú reiknaðir með og gildið sem þú stilltir. Hver sem fer yfir það síðar getur athugað forsenduna í stað þess að leiða hana aftur út úr skjámynd af ping.

Ef forritið virkar við hverja þá stærð sem þú prófaðir, hættu að stilla tölur og skoðaðu stefnuna sem aðskilur virku þjónustuna frá þeirri sem bregst.