Отказ по геолокации в Firebox: сначала найдите этап входа VPN

Кто-то в другой стране не может подключиться, и первый инстинкт — посмотреть на правило, которое даёт доступ к внутренним ресурсам. Это правило срабатывает после допуска, поэтому оно не может быть тем, что отклоняет туннель. Блокирующий этап находится где-то на пути входа, а у Firebox есть более одного пути входа в зависимости от службы VPN. Выполняйте проверки по порядку и остановитесь, как только одна из них объяснит отказ.

Проверка 1: назовите входящую службу

Для Mobile VPN с SSL, Access Portal и BOVPN поверх TLS входящим входом является политика WatchGuard SSLVPN. Примените предполагаемое ограничение там, на фактически настроенной службе, вместо того чтобы выводить его из правила доступа пользователя, которое срабатывает позже.

IPsec идёт другим путём. Встроенная политика IPSec разрешает внешний трафик IPsec к Firebox для соответствующих служб филиала и мобильного VPN и имеет приоритет над политикой IPSec, созданной вручную. Если ваш клиент — IKEv2, вы находитесь на этом втором пути, и политика SSLVPN не имеет значения.

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

Проверка 2: читайте отказ, а не теорию

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

Классификация страны следует за наблюдаемым сетевым источником. Роуминговый пользователь, вышестоящий NAT или другой одобренный путь могут изменить то, что видит Firebox, поэтому подтверждайте адрес, а не описание пользователем своего местоположения. Запросите публичный адрес, который видит клиент, и сравните его с источником в журнале Firebox. Когда они различаются, классификация следует по пути, который никто не упомянул.

Проверка 3: встроенная политика всё ещё владелец?

Если ручная политика IPSec выглядит игнорируемой, проверьте, включена ли всё ещё встроенная. Ручное правило, затенённое встроенным правилом с более высоким приоритетом, и ручное правило, которое является единственным допуском, — это разные конфигурации с одинаково выглядящим интерфейсом.

Решите, какая из них должна владеть путём. Если это ручная политика, встроенную нужно отключить для этого трафика, и именно там начинается следующая проверка.

Проверка 4: спланируйте замену до отключения

Отключение встроенной политики IPSec убирает её допуск для затронутых служб VPN. Это включает туннели филиалов, о которых вы, возможно, не думаете, исправляя подключение одного мобильного пользователя.

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

Активное подключение и последующее пересогласование могут оба зависеть от допуска. Изменение, которое работает для проверенной сессии и срывается при следующей смене ключа, — классический результат замены допуска без проверки продления.

Проверка 5: держите идентичность отдельно от местоположения

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

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

Проверка 6: зафиксируйте и проверьте оба пути

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

Наконец, перечитайте отказ, с которого начали. Если он изменился с отказа по местоположению на сбой аутентификации или авторизации, проблема входа решена, и теперь видна другая. Руководство WatchGuard по отказам IKEv2 — это ссылка на описанный выше порядок этапов.