Windows L2TP вчитува само некои страници: избришете го DF битот на pfSense

Лаптопот се поврзува, внатрешната мрежа се вчитува, а неколку јавни страници заглавуваат. Автентикацијата и рутирањето очигледно работат, што како објаснување ја остава големината на пакетот. Во тунел L2TP/IPsec употребливиот MTU е помал од она што адаптерот и натаму го објавува, а клиентот продолжува да праќа пакети со полна големина со поставен бит „не фрагментирај“. На pfSense портата може да ѝ се нареди да го избрише тој бит, и тоа е најбрзиот начин да се потврди дијагнозата пред правилно да се поправи.

Започнете со страниците што не успеваат

Пред да допрете какво било поставување, забележете кои одредишта не успеваат, а кои успеваат. Ракувањата што остануваат под границата на тунелот завршуваат нормално, додека преносите што бараат сегмент со полна големина запираат на половина пат. Таа поделба е потпис на проблем со големината, а не на филтер, зашто блокирано одредиште не успева при воспоставување на врската, а не среде страницата. Двете набљудувања не чинат ништо и веднаш го стеснуваат пребарувањето.

Проверете со ping што го поставува битот и ја контролира големината на полезниот товар. Најголемиот товар што поминува ви го кажува вистинскиот MTU на патеката, а објавената вредност на адаптерот покажува колку се далеку двете.

Запишете ги двата броја. Поправката зависи од тоа кој е погрешен, а токму парот подоцна го потврдува снимањето.

Што прави DF битот на излезот

Причината за разликата во бројките е инкапсулацијата. IPsec додава ESP, L2TP додава уште еден заглавие, и затоа тунелот носи помалку полезен товар од физичката врска. Windows и натаму пријавува 1500 бајти на адаптерот и поставува „не фрагментирај“ на она што го праќа. Кога таков пакет не се собира, правилниот одговор од портата е ICMP порака што го моли испраќачот да се намали. Затоа тунел што пропушта мали ping може сепак да не успее при преземање датотека.

Таа порака често никогаш не пристигнува. Некој скок може да го филтрира ICMP, или ништо не го создава, а испраќачот ја повторува истата големина додека преносот не се откаже.

Тука тишината е вообичаена појава, затоа симптомот се чита како селективно блокирање. Ништо во дневникот на клиентот не забележува ICMP порака што недостасува.

Опцијата на pfSense и што таа не прави

Опцијата се наоѓа на страницата Систем, Напредно, Огноѕид и NAT со ознака „Избриши неважечки DF битови наместо да ги отфрлаш пакетите“. Наместо да фрли преголем пакет што го носи знамето, филтерот го отстранува знамето и дозволува пакетот да се подели понатаму. Пакетот се смета за неважечки кога не може да го помине излезниот интерфејс во едно парче.

Опцијата ја враќа поврзаноста без допирање на клиентот, затоа е популарна. Таа е и заобиколно решение: фрагментацијата чини CPU и го прави секој изгубен фрагмент поскап.

Се однесува само на проследениот сообраќај, а не на сообраќајот што сам го создава огноѕидот. Истата страница нуди „Оневозможи чистење на огноѕидот“, што ја исклучува нормализацијата целосно, и тоа е многу поширока промена отколку што бара овој проблем.

Помалку широка поправка што го држи TCP нефрагментиран

Речиси сите заглавени текови се TCP, а TCP може да преговара за помал сегмент наместо да се потпира на фрагментација. Ограничувањето на MSS на интерфејсот на тунелот ја препишува објавената вредност за време на ракувањето, така што секоја страна го праќа она што навистина се собира. Патеката тогаш се однесува предвидливо и ниту еден пакет не треба да се дели.

Тоа го остава UDP на откривањето или на опцијата DF. Кога страниците што не успеваат се обични веб-страници, ограничувањето е промената што треба да се претпочита.

Клиентот може да го пријави сопствениот MTU на адаптерот преку netsh interface ipv4 show subinterfaces. Споредете го тој број со она што серверот смета дека е договорено, зашто двете не се секогаш исти. Токму таа вредност оперативниот систем навистина ќе ја користи, што и да пријавило преговарањето.

Потврдете со снимање, потоа ресетирајте ја состојбата

Снимете на двете страни пред да одлучите: една трага каде оди тунелот, и друга каде оди WAN интерфејсот. Пакетите што излегуваат со полна големина без ICMP што се враќа го покажуваат ограничувањето како вистински слој. Одговорите што пристигнуваат и потоа умираат на враќање наместо тоа го покажуваат MTU на тунелот.

Исчистете ја табелата со состојби пред повторен обид, бидејќи постоечките текови ги чуваат старите големини на сегментите. Потоа вчитајте ја страницата што не успеа и читајте го приказот на состојби за двосмерен сообраќај наместо еднострани бројачи. Ако и натаму запира, снимете повторно наместо да пробате друго поле за избор.