Защо TACACS+ заявките от ASA заобикалят VPN тунела на клона

Тунелът на клона работи, потребителите се удостоверяват към отдалечения TACACS+ сървър, а собственият вход на защитната стена все още изтича. Причината не е дефект в тунела: тунел LAN-to-LAN пренася трафик, който съвпада с неговите селектори, а управленският трафик, който ASA генерира за себе си, е отделен поток със свой собствен адрес на източника. Повечето екипи откриват това по време на прозорец за промени, когато единственият администраторски акаунт е този, който се проваля. Третирайте AAA сесията, инициирана от ASA, като поток, който трябва да проектирате, а не като страничен ефект от свързаност, която вече работи.

ASA е клиентът и собственият му трафик се нуждае от собствен път

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

Запишете адреса, който очаквате сървърът да види. Ако не можете да го формулирате в един ред, все още нямате проект.

Интерфейсът в реда aaa-server не е украшение

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

inside е правилният отговор само когато посоченият интерфейс държи адреса, който проектът ви възнамерява да използва като източник. На устройство в клон това често е така; на устройство с няколко частни сегмента може и да не е.

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

Същият справочник с команди документира ограничение при редактиране, което хваща хората по време на миграции: промяната на интерфейса на съществуващ хост изисква премахване и пресъздаване на записа за хоста. Конфигурация, която изглежда редактирана, може да не е влязла в сила и следващият опит за вход все още ще тръгва от стария адрес. Планирайте го като изтриване и добавяне с копие от оригиналния запис пред очите си, а не като корекция на място.

Ако са дефинирани няколко сървъра, променете един и го тествайте, преди да пипате останалите, за да не блокира грешка всички административни пътища наведнъж.

Проверете селекторите, транслацията и обратния път заедно

Три неща трябва да съвпадат, за да пристигне заявката. Селекторите на трафика на тунела, или защитата на тунелния интерфейс, ако използвате такава, трябва да включват собствения източник на ASA и адреса на сървъра; списък със селектори, изграден за потребителски подмрежи, обикновено няма да го направи. Всяко NAT правило по пътя трябва да транслатира този източник последователно, защото сървърът оторизира идентичност на мрежово устройство, която включва адреса, който вижда. И обратният път трябва да съществува, което при тунел, базиран на политики, означава, че далечният край има съвпадащ селектор в другата посока.

От страна на сървъра проверете отделно идентичността на устройството, споделената тайна и административната политика. TACACS+ поддържа удостоверяване, оторизация и отчитане като отделни операции, така че отказ, който пристига след завършен обмен, е отговор на политика, а не транспортна повреда. Ако го четете като мрежов проблем, ще търсите на грешното място.

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

Направете промяната, без да се заключите

Използвайте конзола или независим път за управление, докато променяте отдалеченото административно удостоверяване, и дръжте одобрен локален резервен вариант, докато новият път не проведе реален вход. След това валидирайте тясно: един сървър, едно устройство, едно успешно удостоверяване с адрес на източника, наблюдаван от двата края.

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