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

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

Условие первое: у платформы одна таблица или две

Некоторые фильтры пакетов держат IPv4 и IPv6 в совершенно раздельных наборах правил, поэтому правило, добавленное в один, не действует на другой, пока кто-нибудь его не продублирует. Другие предлагают семью, подходящую для обоих, и транслируют адреса для каждого пакета. Третья группа держит один язык политики, но хранит за ним отдельные объекты для каждой семьи.

Прочитайте документацию того фильтра, который вы действительно используете, затем перечислите, какие таблицы существуют и какую затронуло ваше изменение. Подсчёт правил в таблице IPv4 отвечает на вопрос, который никто не задавал. Затем перечислите, какие таблицы существуют и какую затронуло ваше изменение.

Условие второе: где применяется политика

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

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

Условие третье: что должен делать IPv6

Решите, проходит ли IPv6 через туннель, блокируется ли, пока защита недоступна, или следует документированному исключению. Каждый ответ даёт свой набор правил, а оставленный открытым вопрос — это то, как клиент с собственным IPv6 попадает к пунктам назначения вне туннеля, к которым он попадает внутри него через IPv4.

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

ICMPv6 — это управляющий трафик

Обнаружение соседей и обратная связь по маршруту едут оба на ICMPv6, поэтому сплошное отбрасывание, скопированное с привычки IPv4, ломает адресацию и большие передачи одновременно. Сплошное разрешение тоже не ответ, потому что оно отдаёт канал, за которым никто не следит.

Следуйте рекомендациям по фильтрации для важных типов сообщений, а остальные отклоняйте с указанием причины. Неисправность, которую чаще всего диагностируют неверно, — это отсутствующее сообщение Packet Too Big, которое проявляется как соединение, открывающееся и затем застревающее.

Доказать это, по одной семье за раз

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

Меняйте одно ограниченное правило за попытку и держите под рукой предыдущую конфигурацию. Там, где политикой владеет управляемый профиль, привлеките его администратора до локального редактирования, потому что следующая проверка перезапишет локальное исправление и вернёт утечку.