Облачная группа безопасности для VPN: откройте слушателя, а не всё

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

Назовите протокол до правила

Правило — это протокол, диапазон портов и источник. WireGuard слушает UDP, обычно 51820. OpenVPN обычно работает по UDP или TCP 1194 в зависимости от конфигурации. IPsec нужен обмен IKE на UDP 500 и 4500 плюс сам протокол ESP, который является номером протокола, а не портом. Догадка про TCP потому, что остальные правила TCP, приводит к правилу, которое выглядит правильным и ни с чем не совпадает.

Читайте слушателя из работающей службы, а не из руководства. Демон, привязанный к одному адресу, не примет трафик, приходящий на другой.

Ограничьте источник диапазоном клиентов, который допускает проект, а не всем интернетом.

Группы безопасности хранят состояние; ACL подсети — нет

Группы безопасности хранят состояние и только разрешают: разрешённый входящий поток автоматически получает ответы, и правила запрета, о котором надо думать, нет. ACL подсети не хранят состояние и оцениваются в обе стороны, поэтому входящее разрешение без соответствующего исходящего временного диапазона всё равно не срабатывает. Это различие объясняет многие правила, которые в консоли выглядят правильными.

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

Действующая политика — это объединение привязанного, а не файл, который вы правили.

Брандмауэр хоста — отдельная граница

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

Если хост использует фронтенд брандмауэра дистрибутива, проверьте нижележащие правила, а не имя профиля, потому что профиль может быть активен, пока порт закрыт.

Захват на интерфейсе скажет, какая граница отбросила пакет.

Разрешить слушателя — не значит маршрутизировать клиентов

VPN-шлюзу, который пересылает трафик клиентов, нужно больше, чем открытый порт. Нужна пересылка IP, политика, разрешающая поток от интерфейса туннеля к сети назначения, и часто отключённая проверка источника и назначения на интерфейсе, чтобы платформа не отбрасывала трафик, не адресованный ей. Ничего из этого правило слушателя не создаёт.

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

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

Оставьте путь назад, затем сузьте правило

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

Удалите любое экспериментальное широкое разрешение, как только узкое заработает, и отметьте, почему правило существует. AWS документирует поведение групп безопасности с сохранением состояния, и именно на этот документ ссылаются, когда кто-то предлагает широкий диапазон как сокращение.

Задокументируйте и привязку, иначе сменный интерфейс молча потеряет политику.