Защо пълното блокиране на ICMP чупи работещ път на VPN
Съобщенията за обратна връзка за размера не са отговори на ping. Когато никога не пристигат, малките пакети минават, големите изчезват, а тунелът изглежда като трептящ.
Тунел, който преминава удостоверяване, пренася ping и след това забива при първия голям трансфер, е класическият признак за липсващо ICMP съобщение, а не за счупен VPN. Изпращачът така и не научава, че пакетът е бил твърде голям, повтаря същия размер, а приложението чака. Поправянето е решение на политиката на защитната стена, а не преинсталиране на клиента. Редът е важен: измерете къде се намира границата на размера, след което стеснете правилото, погълнало доклада.
Какво всъщност пренася ICMP по този път
Откриване на MTU на пътя при IPv4 разчита на това маршрутизатор да съобщи, че пакет с установен бит don't-fragment не е могъл да бъде препратен. Този доклад е съобщение ICMP Fragmentation Needed и без него изпращачът няма причина да намали размера на сегмента си. IPv6 е по-строг: маршрутизаторите не фрагментират транзитно, затова съобщението ICMPv6 Packet Too Big е единственият сигнал, който кара изпращача да се свие.
И двете съобщения са обратна връзка на управляващата равнина и нито едно от тях не е диагностично ехо. Политика, която блокира ping, и политика, която блокира целия ICMP, изглеждат сходно в списък с правила и се държат много различно в мрежата. Втората може да превърне правилно оразмерен тунел в еднопосочен път за всичко, по-голямо от най-малкото звено във веригата.
Някои транспорти реализират собствено откриване със сондажни пакети, както описва RFC 4821, и те са по-малко зависими от тази обратна връзка. Това е аргумент да проверите кой транспорт използвате, а не да предполагате, че всеки тунел е имунен.
| Съобщение | Предназначение по пътя | Ако е блокирано |
|---|---|---|
| ICMPv4 тип 3 код 4 | Пакетът беше твърде голям за следващото звено | Изпращачът продължава да опитва и забива |
| ICMPv6 тип 2 | Packet Too Big, еквивалентът при IPv6 | Същото забиване, без резервен вариант за фрагментация |
| ICMP тип 11 | Изтекло време, използва се от traceroute | Диагностиката губи хопове, трафикът продължава да тече |
| ICMP заявка за ехо и отговор | Тест за достъпност | Ping се проваля, пътят може да е наред |
Отказът зависи от размера
Попитайте дали отказът корелира с размера на пакета. Страница за вход, DNS заявка и кратко извикване на API минават, докато качване на файл, голям отговор или изтегляне на изображение забиват. Този модел сочи към ограничение на размера някъде между двата края, а не към удостоверяване или маршрутизация. Успешен малък ping не казва почти нищо за това къде е тази граница.
Вътре в тунела има два слоя за разглеждане: пакетът с полезния товар и външният инкапсулиран пакет. Вътрешният изпращач може да се държи правилно, докато външният път е по-малък, отколкото тунелът предполага, и затова както собствената настройка на MTU на тунела, така и физическата връзка под него имат значение.
Измерете, преди да редактирате правила
Проверете с бит don't-fragment и избран от вас размер на полезния товар, от проблемния клиент към защитен адрес:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7Полезен товар от 1472 байта плюс 28 байта заглавки е пакет от 1500 байта. Ако голямата проба се провали с грешка за фрагментация, а по-малката мине, намерили сте границата; коригирайте за допълнителните разходи на тунела и повтаряйте, докато работещият размер се стабилизира.
След това потвърдете, че пропускът е самият доклад. Ако пробата се провали безшумно, без грешка и без отговор, съобщението вероятно се изхвърля, а не се доставя, и заподозряното е правилото.
Стеснете правилото, след което тествайте задачата отново
Корекцията трябва да разрешава конкретните управляващи съобщения, а не целия протокол. На хост с iptables формата е разрешаване за конкретен тип; адаптирайте синтаксиса към това, което управлява защитната стена на вашата платформа:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTОставете отговорите на ехо блокирани, ако това е местната политика, тъй като пътят не се нуждае от тях. След това тествайте отново трансфера, който първоначално се провали, от нова връзка, и потвърдете, че броячите на правилото показват пристигащи съобщения.
Ако големият трансфер все още забива след разрешаването на съобщенията, оставащото ограничение е другаде: MTU на тунела, зададен твърде високо, прокси, което пренаписва пакети, или междинно устройство, което изхвърля вместо да докладва. Правилото за ICMP беше необходимо, но не достатъчно.