Ваше правило VPN для IPv4 нічого не каже про трафік IPv6

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

Умова перша: у платформи одна таблиця чи дві

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

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

Умова друга: де застосовується політика

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

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

Умова третя: що має робити IPv6

Вирішіть, чи IPv6 проходить через тунель, блокується, поки захист недоступний, чи дотримується задокументованого винятку. Кожна відповідь дає інший набір правил, а залишене відкритим питання — це те, як клієнт із власним IPv6 потрапляє до пунктів призначення поза тунелем, до яких він потрапляє всередині нього через IPv4.

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

ICMPv6 — це керуючий трафік

Виявлення сусідів і зворотний зв'язок щодо шляху їдуть обидва на ICMPv6, тож суцільне відкидання, скопійоване зі звички IPv4, ламає адресацію та великі передачі одночасно. Суцільний дозвіл теж не відповідь, бо він віддає канал, за яким ніхто не стежить.

Дотримуйтеся рекомендацій з фільтрації для важливих типів повідомлень, а решту відхиляйте із зазначенням причини. Несправність, яку найчастіше діагностують неправильно, — це відсутнє повідомлення Packet Too Big, яке проявляється як з'єднання, що відкривається і потім застрягає.

Довести це, по одній родині за раз

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

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