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, — це не тунель, що несе власний голос міжмережевого екрана.