OpenVPN през PPPoE: да намалим link-mtu, tun-mtu или mssfix?

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

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

Три копчета, три различни слоя

link-mtu е външният бюджет: криптираният полезен товар плюс заглавката на OpenVPN, заглавката на UDP и външната заглавка на IP. Той описва какво напуска машината и затова е числото, което физическият път ограничава.

tun-mtu е вътрешният бюджет: интерфейсът, който вашият трафик вижда. Той е точно с размера на тунелните разходи по-голям от това, което пътят може да пренесе, и OpenVPN обикновено го извежда, вместо да ви кара да го задавате.

mssfix е напълно различен механизъм. Той пренаписва максималния размер на сегмента, обявен по време на TCP ръкостисканията, така че TCP партньорите да избират сегменти, които се побират след инкапсулацията. Не променя MTU на интерфейса и няма ефект върху UDP.

Ако зададете link-mtu изрично, OpenVPN изважда собствените си разходи, за да изведе вътрешния MTU. Тези разходи не са фиксирана константа; те зависят от шифъра и удостоверяването, затова стойност, копирана от форумна публикация, може да е грешна в друг профил. Задаването и на link-mtu, и на tun-mtu дава на клиента две противоречиви инструкции.

Измерете пътя, преди да изберете каквото и да е число

Измервайте от физическия интерфейс, не отвътре в тунела, и помнете, че ping съобщава полезния товар, а не размера на пакета. Добавете 28 байта за заглавките на IPv4 и ICMP, преди да сравните товара с кадър от 1500 байта, и дръжте тази корекция в ума, когато партньор съобщи различно число.

При Linux клиент ping -M do -s 1472 забранява фрагментацията и се проваля, ако пакетът е твърде голям. Намалявайте товара, докато мине, след което добавете 28, за да получите MTU на пътя. PPPoE струва 8 байта, затова 1492 е нормално при DSL. DS-Lite и някои мобилни пътища струват 40 или повече, а отговорът обикновено е по-нисък, отколкото номиналната скорост на връзката предполага.

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

Първо свийте TCP, после намалете тунела

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

Намалете вътрешния MTU, когато засегнатият трафик не е TCP. UDP услуга, тунел в тунела или приложение, което изпраща дейтаграми с пълен размер, ще продължат да се провалят след свиване на MSS, защото нищо не пренаписва размера на пакета им. Намалете tun-mtu за този случай или задайте link-mtu и оставете клиента да изведе вътрешната стойност, но никога и двете.

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

Защо малките проверки продължават да работят

DNS заявките, ICMP ехото и TCP ръкостисканията са далеч под размера, при който има провал. Затова тунелът изглежда здрав във всеки бърз тест, докато TLS ръкостисканията и HTTP отговорите тихо се провалят. Тази комбинация — работещ traceroute и браузър, който забива на първия голям отговор — е отпечатъкът, който трябва да търсите. Посегнете към проверка с пълен размер, преди да посегнете към нов профил.

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

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