Windows L2TP indlæser nogle websteder: ryd DF-bitten på pfSense

Bærbaren opretter forbindelse, intranettet indlæses, og en håndfuld offentlige websteder hænger. Godkendelse og routing fungerer tydeligvis, hvilket efterlader pakkestørrelse som forklaring. I en L2TP/IPsec-tunnel er den brugbare MTU mindre, end adapteren stadig annoncerer, og klienten bliver ved med at sende pakker i fuld størrelse med bitten »må ikke fragmenteres« sat. En pfSense-gateway kan få besked om at rydde den bit, og det er den hurtigste måde at bekræfte diagnosen på, før den rettes ordentligt.

Begynd med de sider, der fejler

Noter hvilke destinationer der fejler, og hvilke der lykkes, før du rører nogen indstilling. Håndtryk, der bliver under tunnelgrænsen, fuldføres normalt, mens overførsler, der kræver et segment i fuld størrelse, går i stå halvvejs. Den opdeling er signaturen på et størrelsesproblem og ikke et filter, fordi en blokeret destination fejler ved forbindelsesopbygningen i stedet for midt på siden. Begge observationer koster ingenting og indsnævrer søgningen med det samme.

Test med en ping, der sætter bitten og styrer nyttelastens størrelse. Den største nyttelast, der overlever, fortæller dig den reelle rute-MTU, og adapterens annoncerede værdi viser, hvor langt de to er fra hinanden.

Skriv begge tal ned. Rettelsen afhænger af, hvilket der er forkert, og parret er det, en optagelse senere bekræfter.

Hvad DF-bitten gør på vejen ud

Indkapsling er grunden til, at tallene er forskellige. IPsec tilføjer ESP, L2TP tilføjer endnu en header, og tunnelen bærer derfor mindre nyttelast end det fysiske link. Windows rapporterer stadig 1500 byte på adapteren og sætter »må ikke fragmenteres« på det, den sender. Når en sådan pakke ikke kan være der, er det korrekte svar fra gatewayen en ICMP-meddelelse, der beder afsenderen om at krympe. Derfor kan en tunnel, der klarer små pings, stadig fejle en filhentning.

Den meddelelse ankommer ofte aldrig. Et hop kan filtrere ICMP, eller intet genererer det, og afsenderen gentager den samme størrelse, indtil overførslen giver op.

Stilhed er den normale præsentation her, og derfor læses symptomet som selektiv blokering. Intet i klientens log registrerer en manglende ICMP-meddelelse.

pfSense-indstillingen, og hvad den ikke gør

Indstillingen findes på siden System, Avanceret, Firewall og NAT med etiketten »Ryd ugyldige DF-bits i stedet for at droppe pakkerne«. I stedet for at kassere en for stor pakke, der bærer flaget, fjerner filteret flaget og lader pakken blive opdelt længere fremme. En pakke tæller som ugyldig, når den ikke kan passere den udgående grænseflade i ét stykke.

Indstillingen genopretter forbindelsen uden at røre klienten, og derfor er den populær. Det er også en omvej: fragmentering koster CPU og gør hvert tabt fragment dyrere.

Den gælder kun for videresendt trafik, ikke for trafik, som firewallen selv starter. Samme side tilbyder »Slå firewall-scrub fra«, som slår normalisering helt fra, og det er en meget bredere ændring, end dette problem har brug for.

En snævrere rettelse, der holder TCP uden fragmentering

Næsten alle de fastlåste flows er TCP, og TCP kan forhandle et mindre segment i stedet for at stole på fragmentering. Begrænsning af MSS på tunnelgrænsefladen omskriver den annoncerede værdi under håndtrykket, så hver side sender det, der faktisk kan være der. Ruten opfører sig derefter forudsigeligt, og ingen pakke skal opdeles.

Det overlader UDP til opdagelse eller til DF-indstillingen. Når de fejlende websteder er almindelige websider, er begrænsningen den ændring, man bør foretrække.

Klienten kan rapportere sin egen adapter-MTU via netsh interface ipv4 show subinterfaces. Sammenlign det tal med det, serveren mener at have forhandlet, for de to er ikke altid ens. Den værdi er den, operativsystemet faktisk bruger, uanset hvad forhandlingen rapporterede.

Bekræft med en optagelse, og nulstil derefter tilstanden

Optag på begge sider, før du beslutter: et spor hvor tunnelen kører, og et andet hvor WAN-grænsefladen kører. Pakker, der forlader i fuld størrelse uden ICMP, der vender tilbage, peger på begrænsningen som det rigtige lag. Svar, der ankommer og derefter dør på vejen tilbage, peger i stedet på tunnelens MTU.

Ryd tilstandstabellen, før du prøver igen, da eksisterende flows beholder deres gamle segmentstørrelser. Indlæs derefter den side, der fejlede, og læs tilstandsvisningen for tovejstrafik i stedet for ensidige tællere. Hvis den stadig går i stå, så optag igen i stedet for at prøve endnu et afkrydsningsfelt.