Windows L2TP laddar bara vissa webbplatser: rensa DF-biten på pfSense

Den bärbara datorn ansluter, intranätet laddas och en handfull offentliga webbplatser hänger sig. Autentisering och routning fungerar tydligt, vilket lämnar paketstorleken som förklaring. I en L2TP/IPsec-tunnel är den användbara MTU:n mindre än vad adaptern fortfarande annonserar, och klienten fortsätter att skicka paket i full storlek med «fragmentera inte»-biten satt. En pfSense-gateway kan beordras att rensa den biten, och det är det snabbaste sättet att bekräfta diagnosen innan den åtgärdas ordentligt.

Börja med sidorna som misslyckas

Anteckna vilka destinationer som misslyckas och vilka som lyckas innan du rör någon inställning. Handskakningar som stannar under tunnelgränsen slutförs normalt, medan överföringar som behöver ett segment i full storlek stannar halvvägs. Den uppdelningen är signaturen för ett storleksproblem och inte ett filter, eftersom en blockerad destination misslyckas vid uppkopplingen och inte mitt på sidan. Båda observationerna kostar ingenting och snävar in sökningen direkt.

Testa med en ping som sätter biten och styr nyttolastens storlek. Den största nyttolasten som tar sig igenom anger den verkliga väg-MTU:n, och adapterns annonserade värde visar hur långt ifrån varandra de är.

Skriv ner båda talen. Rättelsen beror på vilket som är fel, och paret är det en inspelning senare bekräftar.

Vad DF-biten gör på vägen ut

Inkapsling är anledningen till att talen skiljer sig. IPsec lägger till ESP, L2TP lägger till ytterligare en header, och tunneln bär därför mindre nyttolast än den fysiska länken. Windows rapporterar fortfarande 1500 byte på adaptern och sätter «fragmentera inte» på det den skickar. När ett sådant paket inte får plats är gatewayens korrekta svar ett ICMP-meddelande som ber avsändaren att krympa. Därför kan en tunnel som släpper igenom små ping fortfarande misslyckas med en filnedladdning.

Det meddelandet kommer ofta aldrig fram. Ett hopp kan filtrera ICMP, eller ingenting genererar det, och avsändaren upprepar samma storlek tills överföringen ger upp.

Tystnad är den normala presentationen här, och därför läses symtomet som selektiv blockering. Ingenting i klientloggen registrerar ett saknat ICMP-meddelande.

pfSense-alternativet, och vad det inte gör

Alternativet finns på sidan System, Avancerat, Brandvägg och NAT, märkt «Rensa ogiltiga DF-bitar i stället för att kasta paketen». I stället för att kasta ett för stort paket som bär flaggan tar filtret bort flaggan och låter paketet delas längre fram. Ett paket räknas som ogiltigt när det inte kan passera det utgående gränssnittet i ett stycke.

Alternativet återställer anslutningen utan att röra klienten, och därför är det populärt. Det är också en kringgång: fragmentering kostar CPU och gör varje förlorat fragment dyrare.

Det gäller bara vidarebefordrad trafik, inte trafik som brandväggen själv skapar. Samma sida erbjuder «Inaktivera brandväggsrensning», vilket stänger av normalisering helt, och det är en mycket bredare ändring än det här problemet behöver.

En snävare rättelse som håller TCP ofragmenterat

Nästan alla fastnade flöden är TCP, och TCP kan förhandla fram ett mindre segment i stället för att förlita sig på fragmentering. Begränsning av MSS på tunnelgränssnittet skriver om det annonserade värdet under handskakningen, så att varje sida skickar det som faktiskt får plats. Vägen beter sig då förutsägbart och inget paket behöver delas.

Det lämnar UDP åt upptäckt eller åt DF-alternativet. När webbplatserna som misslyckas är vanliga webbsidor är begränsningen den ändring man bör föredra.

Klienten kan rapportera sin egen adapter-MTU via netsh interface ipv4 show subinterfaces. Jämför talet med det servern tror har förhandlats, eftersom de två inte alltid är lika. Det värdet är det operativsystemet faktiskt använder, vad förhandlingen än rapporterade.

Bekräfta med en inspelning och återställ sedan tillståndet

Spela in på båda sidor innan du bestämmer dig: ett spår där tunneln går och ett där WAN-gränssnittet går. Paket som lämnar i full storlek utan att ICMP kommer tillbaka pekar på begränsningen som rätt lager. Svar som anländer och sedan dör på vägen tillbaka pekar i stället på tunnelns MTU.

Töm tillståndstabellen innan du försöker igen, eftersom befintliga flöden behåller sina gamla segmentstorlekar. Ladda sedan sidan som misslyckades och läs tillståndsvyn för trafik i båda riktningarna i stället för ensidiga räknare. Om den fortfarande fastnar, spela in igen i stället för att prova en annan kryssruta.