Windows L2TP laai sommige werwe: verwyder die DF-bis op pfSense
’n L2TP-kliënt wat die intranet laai maar op sommige openbare werwe hang, het ’n MTU-probleem. Verwyder die DF-bis of beperk MSS, en bevestig dit dan met ’n opname.
Die skootrekenaar maak verbinding, die intranet laai, en ’n handvol openbare werwe hang. Verifikasie en roetering werk duidelik, wat pakketgrootte as die verklaring laat. Op ’n L2TP/IPsec-tonnel is die bruikbare MTU kleiner as wat die adapter nog adverteer, en die kliënt hou aan om volgrootte-pakkette te stuur met die moenie-fragmenteer-bis gestel. ’n pfSense-poort kan beveel word om daardie bis te verwyder, en dit is die vinnigste manier om die diagnose te bevestig voordat dit behoorlik reggemaak word.
Begin by die bladsye wat misluk
Let op watter bestemmings misluk en watter slaag voordat jy enige instelling aanraak. Handdrukke wat onder die tonnelgrens bly, voltooi normaal, terwyl oordragte wat ’n volgrootte-segment nodig het, halfpad vasval. Daardie skeiding is die kenmerk van ’n grootteprobleem eerder as ’n filter, want ’n geblokkeerde bestemming misluk by verbindingsopstelling eerder as midde-in die bladsy. Albei waarnemings kos niks en vernou die soektog dadelik.
Probeer met ’n ping wat die bis stel en die loonvraggrootte beheer. Die grootste loonvrag wat oorleef, vertel jou die werklike pad-MTU, en die adapter se geadverteerde waarde wys hoe ver die twee uitmekaar is.
Skryf albei getalle neer. Die regstelling hang daarvan af watter een verkeerd is, en die paar is wat ’n opname later bevestig.
Wat die DF-bis op pad uit doen
Inkapseling is die rede waarom die getalle verskil. IPsec voeg ESP by, L2TP voeg nog ’n kop by, en die tonnel dra dus minder loonvrag as die fisiese skakel. Windows rapporteer steeds 1500 grepe op die adapter en stel moenie-fragmenteer op wat dit stuur. Wanneer so ’n pakket nie pas nie, is die korrekte antwoord van die poort ’n ICMP-boodskap wat die sender vra om te krimp. Dit is waarom ’n tonnel wat klein pings deurlaat, steeds ’n lêeraflewering kan laat misluk.
Daardie boodskap kom dikwels nooit aan nie. ’n Hop kan ICMP filtreer, of niks genereer dit, en die sender herhaal dieselfde grootte tot die oordrag opgee.
Stilte is hier die normale aanbieding, en daarom lees die simptoom as selektiewe blokkering. Niks in die kliënt se logboek teken ’n ontbrekende ICMP-boodskap aan nie.
Die pfSense-opsie, en wat dit nie doen nie
Die opsie sit op die bladsy Stelsel, Gevorderd, Firewall en NAT, met die etiket “Maak ongeldige DF-bisse skoon eerder as om die pakkette te laat val”. Eerder as om ’n oorgrootte pakket wat die vlag dra weg te gooi, verwyder die filter die vlag en laat die pakket stroomaf verdeel. ’n Pakket geld as ongeldig wanneer dit nie die uitgaande koppelvlak in een stuk kan oorsteek nie.
Die opsie herstel verbinding sonder om die kliënt aan te raak, en daarom is dit gewild. Dit is ook ’n noodoplossing: fragmentasie kos CPU en maak elke verlore fragment duurder.
Dit geld net vir deurgevoerde verkeer, nie vir verkeer wat die firewall self begin nie. Dieselfde bladsy bied “Skakel firewall-skoonmaak af”, wat normalisering heeltemal afskakel, en dit is ’n veel wyer verandering as wat hierdie probleem nodig het.
’n Nouer regstelling wat TCP ongefragmenteerd hou
Byna al die vasgevalle vloeie is TCP, en TCP kan ’n kleiner segment beding eerder as om op fragmentasie te staatmaak. Om MSS op die tonnelkoppelvlak te beperk, herskryf die geadverteerde waarde tydens die handdruk, sodat elke kant stuur wat werklik pas. Die pad gedra hom dan voorspelbaar en geen pakket hoef verdeel te word nie.
Dit laat UDP aan ontdekking of aan die DF-opsie oor. Wanneer die mislukkende werwe gewone webbladsye is, is die beperking die verandering om te verkies.
Die kliënt kan sy eie adapter-MTU rapporteer deur netsh interface ipv4 show subinterfaces. Vergelyk daardie syfer met wat die bediener dink dit beding het, want die twee is nie altyd dieselfde nie. Daardie waarde is die een wat die bedryfstelsel werklik sal gebruik, ongeag wat die onderhandeling gerapporteer het.
Bevestig met ’n opname en stel dan die toestand terug
Neem aan beide kante op voordat jy besluit: een spoor waar die tonnel loop, nog een waar die WAN-koppelvlak loop. Pakkette wat op volle grootte vertrek sonder dat ICMP terugkom, wys op die beperking as die regte laag. Antwoorde wat aankom en dan op die terugpad sterf, wys eerder op die tonnel-MTU.
Maak die toestandstabel skoon voordat jy weer probeer, want bestaande vloeie hou hul ou segmentgroottes. Laai dan die bladsy wat misluk het en lees die toestande-aansig vir tweerigtingverkeer eerder as eensydige tellers. As dit steeds vasval, neem weer op eerder as om nog ’n keuseblokkie te probeer.