Hvorfor OpenConnect-sider henger til du senker tunnelens MTU

Pålogging lykkes, portalsiden tegnes, og deretter blir en dashbord-widget eller en rapport hengende på waiting for host til nettleseren gir opp. Offentlige nettsteder lastes normalt hele tiden, og ingen påloggingsdetaljer er endret. At små svar kommer gjennom mens store stopper, er signaturen til et tak for pakkestørrelse og ikke en tilgangsregel. Bekreft den lesningen før du endrer noe annet i profilen.

Skill et størrelsesproblem fra et policyproblem

Begynn med å utelukke avvisning. Hvis gatewayen hadde avvist deg, ville tilkoblingen feilet med en gang i stedet for å laste en side halvveis. En tunnel som kommer opp og deretter bare stopper ved større overføringer, forteller deg at den ytre stien ikke kan bære den indre pakken.

Mekanismen er innkapsling. Hver indre pakke får tunnelhoder, så en nyttelast som passet i den fysiske lenken blir en ytre pakke som ikke lenger passer, og alt som bærer do-not-fragment-biten, slippes uten et svar nettleseren kan tolke.

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

Mål taket i stedet for å gjette det. Send prober som nekter fragmentering, og senk nyttelasten trinn for trinn til et svar kommer tilbake, med utgangspunkt i en kommando som ping -M do -s 1472 host. Et svar som klager over at fragmentering trengs mens DF er satt, betyr at verdien fortsatt er for høy. Gjenta på 1462, deretter 1452, og stopp ved den første størrelsen som svarer. Noter tallet sammen med verten du testet, fordi svaret hører til den stien og ikke til protokollen generelt.

Test adressen tunnelen faktisk sender trafikk til. En ytre probe mot gatewayens offentlige navn og en indre probe mot en intern server måler ulike hopp, og ICMP-filtrering på en av dem kan få en sunn sti til å se brutt ut.

Bruk verdien på tunneleenheten

Bruk resultatet på grensesnittet klienten opprettet, ikke på Wi-Fi-adapteren. På en Linux-klient er det ip link set dev tun0 mtu 1300 etterfulgt av ip link show tun0 for å bekrefte at verdien ble tatt i bruk. Bruk det enhetsnavnet klienten rapporterer, siden det varierer med implementasjonen og med hvordan tunnelen ble bygget.

Å senke tunnelens MTU krymper nyttelasten hver pakke bærer, så den samlede gjennomstrømningen faller litt, og det er prisen for ikke å sende store svar i svart hullet. Et mindre tall er ikke automatisk tryggere. Å endre den fysiske adapteren i stedet sprer skaden over hver tilkobling på den lenken, mens for store indre pakker forblir like store.

Bruk først klientens egne MTU-forespørsler

Når du styrer kallet, kan klienten be om en størrelse i stedet for å bli lappet etterpå. --mtu ber serveren om en tunnel-MTU, og --base-mtu erklærer MTU-en til den underliggende stien slik at gatewayen kan utlede tunneltallet. Begge er forespørsler, og klientens håndbok lover ikke at gatewayen vil imøtekomme noen av dem.

Den forskjellen bestemmer arbeidsrekkefølgen din. Prøv forespørselen først og inspiser grensesnittet den gir, og fall deretter tilbake til å sette enheten lokalt hvis verdien gatewayen valgte fortsatt stopper.

Verifiser med overføringen som feilet, og gjør den deretter varig

En lokal ip link endring varer til klienten bygger tunnelen på nytt, noe som skjer ved neste gjentilkobling eller gjenopptakelse. Sett verdien der tilkoblingen starter: en wrapper som kjører klienten og deretter justerer enheten, en systemd-enhet med et ExecStartPost-trinn, eller klientvalget når gatewayen godtar det. Hold den ved siden av profilen i versjonskontroll, så neste person ser hvorfor tallet står der.

Test med forespørselen som feilet, ikke med forsiden. Åpne rapporten, hent vedlegget, eller kjør repository-hentingen som hang, og noter nøyaktig hvor den stopper hvis den fortsatt gjør det. En side som tegnes etter endringen beviser lite, fordi den også ble tegnet før.

Hvis den samme overføringen stopper på samme sted, er MTU-teorien ubevist. Ta opp trafikk på tunnelen og sjekk hvilken side som slutter å sende før du endrer tallet igjen, og hold den forrige verdien notert slik at en tilbakerulling forblir én kommando.