ICMP пренасочвания срещу вашите VPN маршрути: какво наистина се променя

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

Пренасочването е предложение от рутер

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

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

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

IPv4 и IPv6 го доставят по различен начин

В IPv6 аналогичен механизъм се намира в откриването на съседи, а не в ICMPv4, с различни формати на съобщенията и различни правила за валидиране. Понятията си приличат, а пакетите — не. Филтър за прихващане, написан за ICMP тип 5, няма да покаже нищо в мрежа с IPv6, което понякога се чете като доказателство, че не е имало пренасочване.

Политическите ключове също са отделни, така че хост може да приема пренасочвания IPv4 и да игнорира IPv6, или обратното.

Проверете и двете семейства, ако разглежданият поток може да използва което и да е от тях.

Приемането е политика на хоста, а не мрежов факт

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

Настройките за сигурни пренасочвания допълнително ограничават на кои шлюзове може да се вярва.

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

Какво не може да обясни пренасочването

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

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

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

Проверете маршрута, преди да обвините тунела

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

Пренасочването никога не бива да е причината защитен път тихо да стане незащитен, затова политиката за приемане принадлежи в прегледа на дизайна. Определението в RFC 792 остава еталонът за това какво може да каже съобщението IPv4.

Запишете търсенето на маршрут и времевата марка на записа заедно и следващият човек ще може да възпроизведе заключението ви.