Pålogging lukkast, portalsida vert teikna, og deretter vert ein dashbord-widget eller ein rapport hengjande på waiting for host til nettlesaren gir opp. Opne nettstader vert lasta normalt heile tida, og ingen påloggingsdetaljar er endra. At små svar kjem gjennom medan store stoppar, er signaturen på eit tak for pakkestorleik og ikkje ein tilgangsregel. Stadfest den lesinga før du endrar noko anna i profilen.

Skil eit storleiksproblem frå eit policyproblem

Byrj med å utelukke avvising. Viss gatewayen hadde avvist deg, ville tilkoplinga feila med ein gong i staden for å lasta ei side halvvegs. Ein tunnel som kjem opp og deretter berre stoppar ved større overføringar, fortel deg at den ytre stien ikkje kan bera den indre pakka.

Mekanismen er innkapsling. Kvar indre pakke får tunnelhovud, så ein nyttelast som passa i den fysiske lenka vert ei ytre pakke som ikkje lenger passar, og alt som ber do-not-fragment-biten, vert sleppt utan eit svar nettlesaren kan tolke.

Mål taket med do-not-fragment-provar

Mål taket i staden for å gjette det. Send provar som nektar fragmentering, og senk nyttelasta trinn for trinn til eit svar kjem tilbake, med utgangspunkt i ein kommando som ping -M do -s 1472 host. Eit svar som klagar over at fragmentering trengst medan DF er sett, tyder på at verdien framleis er for høg. Gjenta på 1462, deretter 1452, og stopp ved den første storleiken som svarar. Noter talet saman med verten du testa, fordi svaret høyrer til den stien og ikkje til protokollen generelt.

Test adressa tunnelen faktisk sender trafikk til. Ein ytre probe mot det offentlege namnet til gatewayen og ein indre probe mot ein intern server måler ulike hopp, og ICMP-filtrering på ein av dei kan få ein sunn sti til å sjå broten ut.

Bruk verdien på tunneleininga

Bruk resultatet på grensesnittet klienten oppretta, ikkje på Wi-Fi-adapteren. På ein Linux-klient er det ip link set dev tun0 mtu 1300 etterfølgd av ip link show tun0 for å stadfeste at verdien vart teken i bruk. Bruk det einingnamnet klienten rapporterer, sidan det varierer med implementasjonen og med korleis tunnelen vart bygd.

Å senke MTU-en til tunnelen krympar nyttelasta kvar pakke ber, så den samla gjennomstrøyminga fell litt, og det er prisen for ikkje å senda store svar i svarte hòlet. Eit mindre tal er ikkje automatisk tryggare. Å endra den fysiske adapteren i staden spreier skaden over kvar tilkopling på den lenka, medan for store indre pakker held seg like store.

Bruk først dei eigne MTU-førespurnadene til klienten

Når du styrer kallet, kan klienten be om ein storleik i staden for å verta lappa etterpå. --mtu ber serveren om ein tunnel-MTU, og --base-mtu erklærer MTU-en til den underliggjande stien slik at gatewayen kan utleia tunneltalet. Begge er førespurnader, og handboka til klienten lovar ikkje at gatewayen vil imøtekomma nokon av dei.

Den skilnaden avgjer arbeidsrekkjefølgja di. Prøv førespurnaden først og inspiser grensesnittet han gjev, og fall deretter tilbake til å setja eininga lokalt viss verdien gatewayen valde framleis stoppar.

Verifiser med overføringa som feila, og gjer ho deretter varig

Ei lokal ip link endring varer til klienten byggjer tunnelen på nytt, noko som skjer ved neste nye tilkopling eller gjenopptaking. Set verdien der tilkoplinga startar: ein wrapper som køyrer klienten og deretter justerer eininga, ei systemd-eining med eit ExecStartPost-steg, eller klientvalet når gatewayen godtek det. Hald han ved sida av profilen i versjonskontroll, så neste person ser kvifor talet står der.

Test med førespurnaden som feila, ikkje med framsida. Opne rapporten, hent vedlegget, eller køyr repository-hentinga som hang, og noter nøyaktig kvar ho stoppar viss ho framleis gjer det. Ei side som vert teikna etter endringa, beviser lite, fordi ho òg vart teikna før.

Viss den same overføringa stoppar på same stad, er MTU-teorien ubevist. Tak opp trafikk på tunnelen og sjekk kva side som sluttar å senda før du endrar talet igjen, og hald den førre verdien notert slik at ei tilbakerulling held seg til éin kommando.

Relaterte artiklar