Kial OpenConnect-paĝoj haltas ĝis vi malaltigos la tunelan MTU

Ensaluto sukcesas, la ĉefpaĝo de la portalo pentriĝas, kaj poste fenestraĵo de la panelo aŭ raporto restas ĉe waiting for host ĝis la retumilo rezignas. Publikaj retejoj ŝarĝiĝas normale la tutan tempon, kaj neniu akreditaĵo ŝanĝiĝis. Tio, ke malgrandaj respondoj alvenas dum grandaj haltas, estas la signo de plafono de paketa grando, ne de alirregularo. Konfirmu tiun legadon antaŭ ol vi ŝanĝos ion alian en la profilo.

Apartigu grandecan problemon disde politika problemo

Komencu per ekskludo de malakcepto. Se la enirejo malakceptus vin, la konekto fiaskus tuj anstataŭ duone ŝarĝi paĝon. Tunelo, kiu ekfunkcias kaj poste haltas nur ĉe pli grandaj transigoj, diras al vi, ke la ekstera vojo ne povas porti la internan paketon.

La mekanismo estas enkapsuligo. Ĉiu interna paketo gajnas tunelajn kapliniojn, do utilŝarĝo, kiu taŭgas en la fizika ligilo, fariĝas ekstera paketo, kiu ne plu taŭgas, kaj ĉio, kio portas la biton do-not-fragment, estas forĵetata sen respondo, kiun la retumilo povus interpreti.

Mezuru la plafonon per do-not-fragment-provoj

Mezuru la plafonon anstataŭ diveni ĝin. Sendu provojn, kiuj rifuzas fragmentadon, kaj malaltigu la utilŝarĝon paŝon post paŝo ĝis revenas respondo, komencante per komando kiel ping -M do -s 1472 host. Respondo, kiu plendas, ke fragmentado necesas dum DF estas agordita, signifas, ke la valoro ankoraŭ estas tro alta. Ripetu ĉe 1462, poste 1452, kaj haltu ĉe la unua grando, kiu respondas. Notu la nombron kune kun la gastiganto, kiun vi provis, ĉar la respondo apartenas al tiu vojo kaj ne al la protokolo ĝenerale.

Provu la adreson, al kiu la tunelo efektive sendas trafikon. Ekstera provo kontraŭ la publika nomo de la enirejo kaj interna provo kontraŭ interna servilo mezuras malsamajn saltojn, kaj ICMP-filtrado ĉe iu ajn el ili povas igi sanan vojon aspekti rompita.

Apliku la valoron al la tunela aparato

Apliku la rezulton al la interfaco, kiun la kliento kreis, ne al la Wi-Fi-adaptilo. Ĉe Linux-kliento tio estas ip link set dev tun0 mtu 1300 sekvata de ip link show tun0 por konfirmi, ke la valoro akceptiĝis. Uzu ajnan aparatnomon, kiun la kliento raportas, ĉar ĝi varias laŭ la efektivigo kaj laŭ tio, kiel la tunelo estis konstruita.

Malaltigi la tunelan MTU malgrandigas la utilŝarĝon, kiun portas ĉiu paketo, do la amasa trafiko iomete malpliiĝas, kaj tio estas la prezo por ne ĵeti grandajn respondojn en nigran truon. Pli malgranda nombro ne estas aŭtomate pli sekura. Ŝanĝi anstataŭe la fizikan adaptilon disvastigas la damaĝon al ĉiu konekto sur tiu ligilo, dum trograndaj internaj paketoj restas same trograndaj.

Unue uzu la proprajn MTU-petojn de la kliento

Kiam vi regas la alvokon, la kliento povas peti grandecon anstataŭ esti flikita poste. --mtu petas tunelan MTU de la servilo, kaj --base-mtu deklaras la MTU de la suba vojo, por ke la enirejo povu derivi la tunelan nombron. Ambaŭ estas petoj, kaj la manlibro de la kliento ne promesas, ke la enirejo obeos iun ajn el ili.

Tiu distingo fiksas vian laborordon. Unue provu la peton kaj inspektu la interfacon, kiun ĝi produktas, poste reiru al loka agordo de la aparato, se la valoro, kiun la enirejo elektis, ankoraŭ haltas.

Kontrolu per la transigo, kiu fiaskis, poste daŭrigu ĝin

Loka ŝanĝo de ip link daŭras ĝis la kliento rekonstruos la tunelon, kio okazas ĉe la sekva rekonekto aŭ daŭrigo. Metu la valoron tie, kie la konekto komenciĝas: envolvilo, kiu rulas la klienton kaj poste ĝustigas la aparaton, systemd-unuo kun paŝo ExecStartPost, aŭ la klienta opcio, kiam la enirejo akceptas ĝin. Tenu ĝin apud la profilo en versiokontrolo, por ke la sekva persono vidu, kial la nombro estas tie.

Testu per la peto, kiu fiaskis, ne per la ĉefpaĝo. Malfermu la raporton, eltiru la aldonaĵon aŭ rulu la deponejan elprenon, kiu haltis, kaj notu precize, kie ĝi haltas, se ĝi ankoraŭ haltas. Paĝo, kiu pentriĝas post la ŝanĝo, pruvas malmulte, ĉar ĝi pentriĝis ankaŭ antaŭe.

Se la sama transigo haltas ĉe la sama punkto, la MTU-teorio estas nepruvita. Kaptu trafikon sur la tunelo kaj kontrolu, kiu flanko ĉesas sendi, antaŭ ol vi denove ŝanĝos la nombron, kaj tenu la antaŭan valoron notita, por ke retroigo restu unu komando.