CIDR группы в Access Server: адреса участников или сеть ресурсов

В группе Access Server два поля принимают CIDR, и на первый взгляд они выглядят как один и тот же тип ввода: одно описывает адреса, которые получают участники VPN, другое описывает сети, до которых эти участники могут добраться. Заполнение не того поля принимается без ошибки, и именно это делает ошибку дорогой. Первое меняет план адресации туннеля, второе решает, какие получатели разрешены, и ни одно не подразумевает другое. Есть и третий объект, который люди подмешивают к этим двум, подсеть за шлюзом филиала, и он не относится ни к одному из полей.

Тот же синтаксис, другие вопросы

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

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

Распределение: адресное пространство участников

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

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

Разрешение: сети получателей живут в правилах доступа

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

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

Третий объект: подсеть филиала за шлюзом

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

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

Как понять, на что вы смотрите

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

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