Ping через VPN: чому правила для ехо-відповіді проминають зворотний шлях

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

Пакет змінює тип, а не порт

Ехо-запит — це ICMP типу 8, коду 0, він несе ідентифікатор і порядковий номер. Відповідь — типу 0, коду 0, з тим самим ідентифікатором і послідовністю, а кінці IP переставлені. Ці поля визначає RFC 792, і саме ідентифікатор дозволяє відправнику зіставляти відповіді зі своїми запитами.

Те, чого немає, не менш важливе: немає заголовка TCP або UDP, отже, немає й порту, який треба дозволити. Правило, яке називає порт для ехо-відповіді, описує пакет, якого ніколи не буде. Це найпоширеніша помилка в заявках на ping через VPN. Правило виглядає конкретним, не застосовується ні до чого і залишає збій рівно там, де він був.

Пакет визначають три контексти

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

У цих трьох контекстів різні ланцюги правил і різні лічильники, і саме злиття їх в один — причина того, що «брандмауер дозволяє ICMP» усе одно може дати невдалий ping. Зовнішній тунель — четвертий контекст: дозвіл слухачеві VPN не дозволяє автоматично декапсульований внутрішній запит, а внутрішній дозвіл нічого не каже про те, чи піднятий зовнішній тунель.

Фільтри зі станом і без стану обробляють відповідь по-різному

Брандмауер зі станом, який бачив, як запит виходить, може пов’язати відповідь із цим потоком і пропустити її без другого правила. Фільтр без стану не має такої пам’яті, тому зворотному напрямку потрібен власний явний дозвіл, з переставленими джерелом і призначенням.

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

Обмежте те, що дозволяєте. Дозволити будь-яку ехо-відповідь звідусіль — не те саме, що завершити зв’язок зі станом, і номер типу не засвідчує відправника.

Трансляція змінює й ідентифікатор

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

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

Не змішуйте помилки ICMP із політикою ехо

Повідомлення «потрібна фрагментація», яке використовує виявлення MTU шляху, не є ехо-відповіддю, і його корисне навантаження цитує пакет, що його спричинив. Дозвіл лише для ехо, який мовчки відкидає ці помилки, перетворює проблему розміру на зависле з’єднання, що є протилежністю користі.

Та сама обережність стосується родин адрес. ICMPv6 використовує інші типи повідомлень і несе суттєві функції, яких немає в IPv4, тому копіювати ці номери в правило IPv6 просто неправильно.

Коли ехо-обмін працює, перевірте реальний застосунок окремо. Успішний ping доводить круговий шлях одного протоколу за одного розміру до одного призначення, і це не ліцензія припускати, що HTTPS, SMB або будь-який інший потік дозволено.