ICMP-переспрямування проти ваших маршрутів VPN: що насправді змінюється

Потік, який мав би йти через тунель, обирає інший наступний вузол, і хтось знаходить ICMP-переспрямування в перехопленні. Це гіпотеза, а не діагноз. Переспрямування — це підказка маршрутизатора про кращий наступний вузол, і те, чи хост почне їй слідувати, залежить від налаштувань, які різняться за платформою, за інтерфейсом і за родиною адрес.

Переспрямування — це підказка від маршрутизатора

У ICMP-переспрямувань IPv4 є власний тип повідомлення і вузький набір умов: маршрутизатор надсилає пакет через той інтерфейс, з якого він прийшов, і знає на тому самому каналі наступний вузол, ближчий до призначення. Далі він каже відправникові використовувати цей вузол напряму. Повідомлення називає новий шлюз і містить частину початкового пакета, щоб відправник міг зіставити його з потоком. Це ввічливе повідомлення про локальну топологію, і воно припускає, що відправник перебуває на тому самому каналі, що й запропонований шлюз.

Відправник має право його ігнорувати. Протокол не вимагає від хоста змінювати таблицю, а перехоплене переспрямування доводить лише те, що маршрутизатор його надіслав.

Саме на цій відмінності помиляється більшість розслідувань переспрямувань.

IPv4 та IPv6 доставляють його по-різному

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

Налаштування політики теж окремі, тому хост може приймати переспрямування IPv4 й ігнорувати IPv6, або навпаки.

Перевіряйте обидві родини, якщо розглянутий потік може використовувати будь-яку з них.

Приймання — це політика хоста, а не факт мережі

У Linux приймання переспрямувань керується на інтерфейс і глобально, а типові значення різняться для ролі хоста й ролі маршрутизатора. Тунельний інтерфейс, що приймає переспрямування, — дивне рішення, адже всередині тунелю точка-точка немає осмисленого альтернативного наступного вузла на тому самому каналі. Тому це налаштування варто прочитати, а не припускати.

Налаштування безпечних переспрямувань додатково обмежують, яким шлюзам можна вірити.

Якщо ви посилюєте хост, переглянути треба саме ці параметри, і вони ж пояснюють, чому дві машини в одній мережі можуть поводитися по-різному. Змінюйте їх як політику, а не як лазівку під час налагодження.

Чого переспрямування не може пояснити

Конкретні маршрути, правила маршрутизації за політикою та локальні інтерфейси пояснюють більшість несподіваних шляхів без жодного переспрямування. Конкретніший префікс, правило, що збігається з адресою джерела, або другий маршрут за замовчуванням в іншій таблиці кожен із них перекриває маршрут, який ви очікували. Перевірте їх першими, бо вони детерміновані й видимі.

Застаріле перехоплення — друга пастка, адже клієнт, який змінив мережу, має інший локальний шлюз.

Старе переспрямування з попереднього підключення нічого не пояснює про поточний шлях, тому запишіть, який інтерфейс зараз отримує керуючий трафік.

Перевірте маршрут, перш ніж звинувачувати тунель

Запитайте ядро, який маршрут воно використало б для призначення, потім порівняйте його з таблицею, яку ви мали на увазі. Якщо відповідь збігається з таблицею, жодне переспрямування нічого не змінило, і розслідування належить іншому місцю. Якщо не збігається, перш ніж вважати тунель винним, пошукайте кешоване переспрямування, правило політики або другу таблицю. Перевірка маршруту — це істина, а все інше — історія про те, як так сталося.

Переспрямування ніколи не має бути причиною того, що захищений шлях тихо стає незахищеним, тому політика приймання належить до проєктного огляду. Визначення в RFC 792 лишається орієнтиром для того, що може повідомляти IPv4-повідомлення.

Запишіть результат перевірки маршруту й мітку часу перехоплення разом, і наступна людина зможе відтворити ваш висновок.