Почему запросы TACACS+ самой ASA обходят туннель VPN филиала

Туннель филиала поднят, пользователи аутентифицируются на удалённом сервере TACACS+, а вход самой межсетевой экрана всё равно завершается по таймауту. Причина не в ошибке туннеля: туннель LAN-to-LAN передаёт трафик, соответствующий его селекторам, а управляющий трафик, который ASA генерирует о себе, — это отдельный поток с собственным адресом источника. Большинство команд обнаруживают это в окно изменений, когда единственная учётная запись администратора — та, что не работает. Относитесь к сеансу AAA, инициированному ASA, как к потоку, который нужно спроектировать, а не как к побочному эффекту уже работающего подключения.

ASA — это клиент, и его собственный трафик требует собственного пути

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

Запишите адрес, который, по вашему ожиданию, увидит сервер. Если вы не можете сформулировать его одной строкой, проекта у вас ещё нет.

Интерфейс в строке aaa-server — это не украшение

На ASA запись хоста aaa-server принимает привязку к интерфейсу в скобках, и справочник команд хоста AAA от Cisco описывает её как интерфейс, на котором находится сервер аутентификации. Именно эта привязка связывает запрос с интерфейсом и с политикой, которую применяет этот интерфейс. Выбор её по тому интерфейсу, который смотрит в интернет, или оставление того, что осталось от последней миграции, даёт адрес источника, для которого удалённый сервер и туннель никогда не строились.

inside — правильный ответ только тогда, когда указанный интерфейс содержит адрес, который ваш проект намерен использовать как источник. На устройстве филиала это часто так; на устройстве с несколькими частными сегментами, возможно, нет.

Изменение привязки означает пересоздание записи

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

Если определено несколько серверов, измените один и проверьте его, прежде чем трогать остальные, чтобы одна ошибка не заблокировала все административные пути сразу.

Проверяйте селекторы, трансляцию и обратный путь вместе

Три вещи должны совпасть, чтобы запрос дошёл. Селекторы трафика туннеля, или защита интерфейса туннеля, если вы её используете, должны включать собственный источник ASA и адрес сервера; список селекторов, построенный для подсетей пользователей, обычно этого не делает. Любое правило NAT на пути должно согласованно транслировать этот источник, потому что сервер авторизует идентичность сетевого устройства, включающую тот адрес, который он видит. И обратный путь должен существовать, что для туннеля на основе политик означает наличие на дальнем конце соответствующего селектора в обратном направлении.

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

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

Внесите изменение, не заперев себя снаружи

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

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