VPN-клиенты ASA получают адреса из неправильного пула DHCP

Читайте dhcp-server и dhcp-network-scope на ASA как два разных поля, задайте scope как маршрутизируемый адрес вне пула и затем проверьте маршрут.

Клиенты AnyConnect появляются в неправильной подсети, или DHCP-сервер вообще отказывается что-либо выдавать, а групповая политика на первый взгляд выглядит правильно. На ASA есть два поля в двух местах, которые оба звучат как «откуда берутся адреса», и установка неправильного даёт ровно это. Профиль подключения называет DHCP-сервер; групповая политика называет подсеть, из которой этот сервер должен выбирать. Ни одно из них не создаёт пул.

Три объекта, три вопроса

Сначала отделите модель распределения от пула, потому что две модели не разделяют конфигурацию. Если ASA сам раздаёт адреса, вы определяете локальный пул и направляете на него групповую политику. Если их раздаёт внешний DHCP-сервер, профиль подключения называет этот сервер, а групповая политика даёт подсказку scope. Смешивание двух и есть обычная причина того, что адрес никогда не появляется.

IntentObjects involved
ASA allocates from its own poolip local pool plus the group policy's address-pool
External DHCP allocatesdhcp-server on the tunnel group, dhcp-network-scope on the group policy

Прочитайте действующие значения, прежде чем менять одно из них

Пропущенная строка — не то же самое, что явный none. Текущая конфигурация показывает, что вы ввели; show run all group-policy показывает, к чему политика фактически сводится, включая унаследованные значения по умолчанию. Проверьте оба, прежде чем решить, что scope неверен, потому что групповая политика, наследующая от политики по умолчанию, может дать значение, которое никогда не появляется в коротком списке.

show running-config group-policy RemoteStaff
show run all group-policy RemoteStaff
show running-config tunnel-group RemoteStaff
group-policy RemoteStaff attributes
 dhcp-network-scope ?

? стоит прочитать на вашей установленной версии, потому что допустимые значения и их текст справки различаются между версиями. Справочник Cisco ASA 9.24 по групповой политике описывает атрибут как маршрутизируемый адрес в нужной подсети, вне пула распределения, с предпочтением адреса интерфейса. Это не диапазон пула и не номер сети.

Задайте scope как адрес, а не диапазон

Предположим, пул, который вы хотите, чтобы использовал сервер, — это 10.50.30.50 по 10.50.30.200 в /24, а интерфейс ASA в этом сегменте — 10.50.30.1. Значение scope — 10.50.30.1. Запись 10.50.30.0 не работает, потому что это номер сети, а запись диапазона не работает, потому что атрибут принимает один адрес. Если выбранный адрес не является адресом интерфейса, ему нужен статический маршрут, чтобы ответ DHCP-сервера мог до него дойти.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Этот фрагмент делает только одно. Он не настраивает DHCP-сервер, не создаёт там пул и не превращает частичный профиль удалённого доступа в рабочий. Описанное здесь поведение — только IPv4; не ожидайте, что оно будет управлять DHCPv6 или делегированием префикса.

Измените это с точкой отката

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

copy running-config flash:pre-dhcp-scope.cfg
conf t
 group-policy RemoteStaff attributes
  no dhcp-network-scope
  dhcp-network-scope 10.50.30.1
 end
write memory

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

Проверьте адрес, маршрут и разрешения

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

show vpn-sessiondb detail anyconnect filter name testuser
show ip local pool
show route | include 10.50.30
ping 10.50.30.61 source inside

Если сессия показывает нужный адрес, но трафик умирает, scope как подозреваемый снят. Посмотрите на обратный маршрут, настройки split-tunnel или фильтры в групповой политике и на то, находится ли scope DHCP в сегменте, куда ASA действительно маршрутизирует.

Похожие статьи