Hvers vegna OpenConnect-síður hanga þar til þú lækkar MTU göngunnar

Innskráning heppnast, forsvarsíða gáttarinnar teiknast, og þá situr mælaborðsgræja eða skýrsla á waiting for host þar til vafrinn gefst upp. Opinberar vefsíður hlaðast venjulega allan tímann, og engum skírteini hefur verið breytt. Það að lítil svör berist á meðan stór stöðvast er einkenni á þaki pakkastærðar en ekki aðgangsreglu. Staðfestu þennan lestur áður en þú breytir einhverju öðru í sniðinu.

Aðgreindu stærðarvandamál frá stefnuvandamáli

Byrjaðu á að útiloka höfnun. Ef gáttin hefði hafnað þér hefði tengingin mistekist samstundis í stað þess að hlaða síðu hálfa. Göng sem koma upp og stöðvast svo aðeins við stærri flutninga segja þér að ytri slóðin geti ekki borið innri pakkann.

Aðferðin er umslöppun. Sérhver innri pakki fær haus göngunnar, svo gagnsemi sem passaði í líkamlegu tenginguna verður ytri pakki sem passar ekki lengur, og allt sem ber do-not-fragment-bitið er hent án svars sem vafrinn getur túlkað.

Mældu þakið með do-not-fragment-prufum

Mældu þakið í stað þess að giska á það. Sendu prufur sem neita sundrungu og lækkaðu gagnsemi skref fyrir skref þar til svar kemur til baka, byrjaðu á skipun eins og ping -M do -s 1472 host. Svar sem kvartar yfir að sundrungu sé þörf meðan DF er stillt þýðir að gildið er enn of hátt. Endurtaktu á 1462, svo 1452, og stöðvaðu á fyrstu stærð sem svarar. Skráðu töluna ásamt vélinni sem þú prófaðir, því svarið tilheyrir þeirri slóð og ekki samskiptareglunni almennt.

Prófaðu netfangið sem göngin senda umferð raunverulega á. Ytri prufa gegn opinberu nafni gáttarinnar og innri prufa gegn innri þjóni mæla mismunandi stökk, og ICMP-síun á öðru hvoru getur látið heilbrigða slóð líta brotna út.

Notaðu gildið á tæki göngunnar

Notaðu niðurstöðuna á viðmótið sem biðlarinn bjó til, ekki á Wi-Fi-adaptarinn. Á Linux-biðlara er það ip link set dev tun0 mtu 1300 og svo ip link show tun0 til að staðfesta að gildið hafi tekið gildi. Notaðu hvaða tækisnafn sem biðlarinn tilkynnir, því það er breytilegt eftir útfærslunni og hvernig göngin voru byggð.

Að lækka MTU göngunnar minnkar gagnsemi sem hver pakki ber, svo afkastageta lækkar aðeins, og það er verðið fyrir að henda ekki stórum svörum í svarthol. Minni tala er ekki sjálfkrafa öruggari. Að breyta líkamlega adaptarnum í staðinn dreifir skaðanum yfir hverja tengingu á þeirri tengingu á meðan of stórir innri pakkar verða jafn of stórir.

Notaðu fyrst eigin MTU-beiðnir biðlarans

Þegar þú stjórnar kallsins getur biðlarinn beðið um stærð í stað þess að vera lappaður eftir á. --mtu biður þjóninn um MTU göngunnar, og --base-mtu lýsir yfir MTU undirliggjandi slóðar svo gáttin geti leitt út tölu göngunnar. Bæði eru beiðnir, og handbók biðlarans lofar því ekki að gáttin virði aðra hvora.

Þessi greinarmunur ræður vinnulagi þínu. Prófaðu beiðnina fyrst og skoðaðu viðmótið sem hún framleiðir, og farðu svo aftur í staðbundna stillingu tækisins ef gildið sem gáttin valdi stöðvast enn.

Staðfestu með flutningnum sem mistókst, og gerðu hann svo varanlegan

Staðbundin ip link breyting endist þar til biðlarinn byggir göngin upp á ný, sem gerist við næstu endurtengingu eða endurupptöku. Settu gildið þar sem tengingin hefst: umbúðir sem keyra biðlarann og stilla svo tækið, systemd-eining með ExecStartPost-skrefi, eða valkostur biðlarans þegar gáttin samþykkir hann. Haltu því við hlið sniðsins í útgáfustýringu svo næsta manneskja sjái hvers vegna talan er þar.

Prófaðu með beiðninni sem mistókst, ekki með forsvarsíðunni. Opnaðu skýrsluna, sæktu viðhengið eða keyrðu skjalasafnssóknina sem hægði á, og skráðu nákvæmlega hvar hún stöðvast ef hún stöðvast enn. Síða sem teiknast eftir breytinguna sannar litla, því hún teiknaðist líka áður.

Ef sami flutningur stöðvast á sama stað, er MTU-kenningin ósönnuð. Taktu umferð á göngunum og athugaðu hvor hliðin hættir að senda áður en þú breytir tölunni aftur, og hafðu fyrra gildi skráð svo afturköllun verði ein skipun.