Почему удалённый пользователь ASA доходит до подсети, но не до приложения
Маршруты доказывают, что туннель работает, а не что пользователь может открыть приложение. Прочитайте фильтр, полученный сессией, и проверьте разрешённое и запрещённое подключение.
Ваш пользователь подключается, получает адрес, пингует сервер в подсети приложения и всё равно не может открыть службу на нём. Такое сочетание для ASA обычно, потому что успешный туннель и пригодное разрешение определяются разными настройками. Список разделённого туннеля выбирал, какие назначения попадут в туннель; фильтр VPN и собственные правила доступа назначения решают, чего может достичь расшифрованный запрос. Пройдите три решения по порядку, а не расширяйте список маршрутов, пока что-то не изменится.
Три решения, которые легко перепутать
Допуск отвечает, может ли пользователь вообще построить туннель: учётные данные, сертификат и любой второй фактор. Выбор маршрута отвечает, какие назначения клиент отправляет в этот туннель. Авторизация отвечает, может ли расшифрованный запрос достичь службы. Только третье создаёт ошибку, о которой сообщает пользователь.
Быстрый способ их различить — спросить, что сломает изменение. Удаление маршрута из разделённого списка останавливает трафик к этой подсети, ничего не предоставляя; добавление ACE в фильтр VPN даёт назначение, не меняя того, что клиент туннелирует.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Прочитайте фильтр, который сессия фактически получила
Начните с живой сессии, а не с конфигурации, которая, по вашему мнению, действует. show vpn-sessiondb detail anyconnect выводит назначенную групповую политику и имя фильтра, привязанного к этой сессии. Если поле пусто, ни один фильтр ничего не применяет, и блокировка приходит откуда-то ещё.
Затем прочитайте политику, владеющую значением, включая значения по умолчанию, потому что фильтр может наследоваться, а не быть записан там, куда вы смотрите:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Сравните имя фильтра в сессии с ACL, который вы только что изменили. ACL с похожим именем, который пользователь никогда не получал, не может изменить политику ресурсов этой сессии, и это самая частая причина, почему внешне правильное изменение не даёт эффекта.
Приоритет объясняет остальное. Для настройки фильтра запись DAP важнее атрибутов имени пользователя, а атрибуты имени пользователя важнее групповой политики. Когда сессия показывает неожиданный фильтр, поищите политику DAP, соответствующую этому пользователю, прежде чем трогать группу.
Разделённый список и фильтр — разные поля
В ASA 9.x групповая политика хранит split-tunnel-network-list и vpn-filter как разные настройки, и руководство по групповым политикам 9.22 документирует их отдельно именно поэтому. Список сетей — подсказка маршрутизации для клиента; фильтр — список управления доступом, применяемый к расшифрованному трафику.
Это различие важно, когда пользователю нужна одна служба HTTPS в подсети. Поместите подсеть в разделённый список, чтобы пакеты вошли в туннель, а затем разрешите в фильтре только эту службу. Расширение списка маршрутов ничего не авторизует, а его сужение не является механизмом принуждения.
Проверьте, находится ли ACL интерфейса вообще на пути
Расшифрованный трафик удалённого доступа не всегда проходит через ACL внешнего интерфейса так, как люди предполагают. Там, где sysopt connection permit-vpn включён, ASA применяет задокументированный обход VPN для этого трафика, а применимые фильтры VPN продолжают действовать после этого. Проверьте настройку командой show run all sysopt вместо рассуждений по схеме топологии.
В любом случае собственный межсетевой экран хоста назначения и авторизация приложения остаются на пути. Правило ASA, разрешающее TCP 443, не заставляет приложение принять пользователя.
Примите изменение и с запрещённым подключением
Один разрешённый тест доказывает очень мало, потому что работающий туннель создаёт тот же первый пакет независимо от наличия фильтра. Откройте нужную службу с клиента, затем попробуйте назначение, которое должно остаться закрытым, и убедитесь, что оно терпит неудачу по правильной причине.
Запишите четыре факта при закрытии заявки: допущенную личность, политику и фильтр, которые сессия фактически получила, назначения в разделённом списке и ресурс, к которому пользователю было разрешено попасть. Эти четыре объясняют, где контролируется трафик, не превращая список маршрутов в межсетевой экран.
Если служба по-прежнему отказывает после того, как фильтр её разрешил, перейдите к хосту: адрес прослушивания, межсетевой экран хоста и собственное сопоставление пользователей приложения. В этот момент туннель сделал своё дело, и дальнейшие изменения в ASA только добавляют риск.