VPN между площадками работает, но журналы ASA не приходят: проверьте адрес источника

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

Что приходит, а что нет

Начните с разделения двух потоков, которые на панели выглядят одинаково. Пересылаемый трафик проходит через ASA: хост LAN отправляет коллектору, ASA сопоставляет его с политикой туннеля, шифрует, и коллектор видит адрес хоста. Создаваемый трафик начинается на самой ASA: устройство строит пакет syslog, выбирает выходной интерфейс и источник и только потом спрашивает, подходит ли какая-либо политика туннеля. Первый поток доказывает, что туннель работает, и ничего не говорит о втором.

Событие, буферизованное на устройстве, тоже не доказательство удалённой доставки, потому что журнал может существовать локально и никогда не отправляться. Проверьте счётчики приёма на коллекторе, прежде чем винить туннель, потому что пустой счётчик — это другой вывод, чем растущий.

Созданное сообщение — это не пересылаемый трафик

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

Если политика защищает 10.20.0.0/24, а ASA использует в качестве источника свой внешний адрес, пакет журнала либо уходит открытым текстом к коллектору, до которого не может добраться, либо отбрасывается. Оба результата со стороны коллектора выглядят одинаково. То же рассуждение относится к управляющему трафику, поэтому management-access — отдельное проектное решение.

Какой источник ASA помещает в сеть

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

Некоторые версии позволяют привязать источник журналирования к интерфейсу, и справочник команд для вашей версии является авторитетом в том, существует ли эта опция и что она меняет. Команда source-interface с другой платформы Cisco не действует на ASA автоматически.

Если вы всё же измените источник, сделайте это осознанно и запишите, потому что ACL коллектора и любая корреляция на основе syslog зависят от него.

Согласуйте селектор с потоком журналов

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

У стороны коллектора свои требования: ACL, разрешающий источник ASA, обратный маршрут и служба прослушивания на порту, который вы настроили. Транспорт здесь тоже важен, потому что журналирование по TCP и TLS ведёт себя иначе, чем UDP, на частично заблокированном пути. Меняйте по одному элементу, иначе следующий снимок не скажет, какое изменение имело значение.

Проверьте на коллекторе, затем запишите источник

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

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

Справочник часто задаваемых вопросов по журналированию ASA от Cisco описывает случай с внешним источником, которому нужно соответствующее определение защищённого трафика, а его пример с внутренним источником включает и хост журналирования внутри, и management-access внутри. Рассматривайте документированную комбинацию и контекст программного обеспечения вместе, а не предполагайте, что одна скопированная строка подходит к любой конфигурации.

Туннель, который несёт трафик LAN, — это не туннель, который несёт собственный голос межсетевого экрана.