Статические адреса туннеля в pfSense: предпочтение или резервирование?

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

Что на самом деле обещает адрес переопределения

Клиентское переопределение содержит параметры для отдельного клиента, включая предпочтительный адрес туннеля. Netgate описывает этот адрес как предпочтение, а не как резервирование, то есть динамический пул не отдаёт адрес никому другому.

Обычно это нормально. Коллизия редка, и клиент обычно получает запрошенное, чего достаточно для удобства и недостаточно для авторизации. Удобство и авторизация — разные требования, и только одно из них переживает коллизию.

При топологии подсети поле принимает адрес клиента вместе с маской сети сервера, поэтому адрес внутри туннеля 10.90.0.0/24 записывается как 10.90.0.10/24.

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

Закройте динамический путь ограниченным значением по умолчанию

Альтернатива — сервер только со статическими адресами: у каждой допущенной конечной точки есть собственная идентичность и собственный уникальный адрес, и больше ничего не проходит.

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

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

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

Сопоставляйте с той идентичностью, которую сервер действительно использует

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

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

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

Напишите правила доступа после того, как карта верна

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

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

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

Проверьте отрицательные случаи

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

Проверьте IPv6 отдельно, поскольку политика адресов IPv4 ничего не говорит о втором стеке. Затем подтвердите, что приложение по-прежнему авторизует пользователя, потому что адрес туннеля — это сетевой факт, а не доказательство того, кто за клавиатурой. Обе проверки должны быть в приёмочной записке.

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