Чому запити TACACS+ самої ASA оминають VPN-тунель вашої філії

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

ASA — це клієнт, і його власний трафік потребує власного шляху

Коли міжмережевий екран звертається до сервера TACACS+, він є клієнтом, як і будь-який інший, з тією різницею, що ніхто навмисно не налаштував для нього маршрут. Його пакети походять з адреси інтерфейсу на пристрої, вони створюються локально, а не пересилаються, і їх треба маршрутизувати, транслювати та захищати політикою так само, як трафік користувачів. Тунель між майданчиками, що захищає підмережу користувачів, не захищає автоматично це джерело керування, бо вибір трафіку ґрунтується на адресах, а не на намірі.

Запишіть адресу, яку, за вашим очікуванням, побачить сервер. Якщо ви не можете сформулювати її одним рядком, проєкту у вас ще немає.

Інтерфейс у рядку aaa-server — це не прикраса

На ASA запис хоста aaa-server приймає прив'язку до інтерфейсу в дужках, і довідник команд хоста AAA від Cisco описує її як інтерфейс, на якому розташований сервер автентифікації. Саме ця прив'язка пов'язує запит з інтерфейсом і з політикою, яку застосовує цей інтерфейс. Вибір її за тим інтерфейсом, що дивиться в інтернет, або залишення того, що залишилося від останньої міграції, дає адресу джерела, для якої віддалений сервер і тунель ніколи не будувалися.

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

Зміна прив'язки означає перестворення запису

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

Якщо визначено кілька серверів, змініть один і перевірте його, перш ніж чіпати інші, щоб одна помилка не заблокувала всі адміністративні шляхи одразу.

Перевіряйте селектори, трансляцію та зворотний шлях разом

Три речі мають збігтися, щоб запит дійшов. Селектори трафіку тунелю, або захист інтерфейсу тунелю, якщо ви його використовуєте, мають включати власне джерело ASA та адресу сервера; список селекторів, побудований для підмереж користувачів, зазвичай цього не робить. Будь-яке правило NAT на шляху має послідовно транслювати це джерело, бо сервер авторизує ідентичність мережевого пристрою, що включає адресу, яку він бачить. І зворотний шлях має існувати, що для тунелю на основі політик означає наявність на дальньому кінці відповідного селектора у зворотному напрямку.

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

Тримайте секрет поза перехопленнями, заявками та розшифровками, поки налагоджуєте, і пам'ятайте, що адреса джерела, яку записує сервер, — це та, яку ваш проєкт має пояснити.

Внесіть зміну, не замкнувши себе ззовні

Використовуйте консоль або незалежний шлях керування, поки змінюєте віддалену адміністративну автентифікацію, і тримайте схвалений локальний резервний варіант, доки новий шлях не проведе реальний вхід. Потім перевіряйте вузько: один сервер, один пристрій, одна успішна автентифікація з адресою джерела, спостереженою на обох кінцях.

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