Защо страниците на OpenConnect забиват, докато не намалите MTU на тунела

Влизането успява, началната страница на портала се изчертава, а след това джаджа на таблото или отчет остава на waiting for host, докато браузърът се откаже. Публичните сайтове се зареждат нормално през цялото време и нито едни идентификационни данни не са се променили. Пристигането на малки отговори, докато големите забиват, е подписът на таван на размера на пакета, а не на правило за достъп. Потвърдете това четене, преди да промените нещо друго в профила.

Отделете проблем със размера от проблем с политиката

Започнете с изключване на отказа. Ако шлюзът ви беше отказал, връзката щеше да се провали веднага, вместо да зареди страница наполовина. Тунел, който се вдига и след това забива само при по-големи трансфери, ви казва, че външният път не може да носи вътрешния пакет.

Механизмът е инкапсулация. Всеки вътрешен пакет получава заглавки на тунела, така че полезният товар, който се побира във физическата връзка, става външен пакет, който вече не се побира, и всичко, носещо бита do-not-fragment, се изхвърля без отговор, който браузърът да разбере.

Измерете тавана с DF проби

Измерете тавана, вместо да го гадаете. Изпращайте проби, които отказват фрагментация, и намалявайте товара стъпка по стъпка, докато върне отговор. Започнете с команда като ping -M do -s 1472 host. Отговор, който се оплаква, че е нужна фрагментация, докато DF е зададен, означава, че стойността все още е твърде висока. Повторете на 1462, след това на 1452, и спрете на първия размер, който върне отговор. Запишете числото заедно с хоста, който сте пробвали, защото отговорът принадлежи на този път, а не на протокола като цяло.

Пробвайте адреса, към който тунелът действително изпраща трафик. Външна проба срещу публичното име на шлюза и вътрешна проба срещу вътрешен сървър измерват различни хопове и филтрирането на ICMP при всеки от тях може да направи здрав път да изглежда счупен.

Приложете стойността към устройството на тунела

Приложете резултата към интерфейса, който клиентът е създал, а не към Wi-Fi адаптера. При Linux клиент това е ip link set dev tun0 mtu 1300 , последвано от ip link show tun0 , за да потвърдите, че стойността е приета. Използвайте името на устройството, което клиентът докладва, тъй като то варира според реализацията и според това как е изграден тунелът.

Намаляването на MTU на тунела свива товара, който носи всеки пакет, така че общата пропускателна способност пада малко и това е цената да не изхвърляте големи отговори в черна дупка. По-малкото число не е автоматично по-безопасно. Промяната на физическия адаптер вместо това разпръсква щетата върху всяка връзка на този канал, като оставя прекалено големите вътрешни пакети също толкова големи.

Първо използвайте собствените заявки за MTU на клиента

Когато контролирате извикването, клиентът може да поиска размер, вместо да бъде поправян след това. --mtu иска MTU на тунела от сървъра, а --base-mtu обявява MTU на подлежащия път, за да може шлюзът да изведе числото за тунела. И двете са заявки и ръководството на клиента не обещава, че шлюзът ще уважи която и да е от тях.

Това разграничение определя реда на работа. Опитайте първо заявката и прегледайте интерфейса, който тя създава, след което се върнете към локално задаване на устройството, ако избраната от шлюза стойност все още забива.

Проверете с трансфера, който се провали, след което го направете постоянен

Локална промяна на ip link трае, докато клиентът не изгради тунела наново, което се случва при следващото повторно свързване или възобновяване. Поставете стойността там, където започва връзката: обвивка, която стартира клиента и след това настройва устройството, systemd unit със стъпка ExecStartPost, или опцията на клиента, когато шлюзът я приеме. Дръжте го до профила в система за контрол на версиите, за да види следващият човек защо числото е там.

Тествайте със заявката, която се провали, а не с началната страница. Отворете отчета, изтеглете прикачения файл или изпълнете извличането от хранилището, което заби, и отбележете точно къде спира, ако все още спира. Страница, която се изчертава след промяната, доказва малко, защото се изчертаваше и преди.

Ако същият трансфер забива в същата точка, теорията за MTU е недоказана. Заснемете трафик на тунела и проверете коя страна спира да изпраща, преди да промените числото отново, и пазете предишната стойност записана, за да остане връщането назад една команда.