Зошто TACACS+ барањата на ASA ја заобиколуваат VPN тунелот на вашата филијала

Тунелот на филијалата е активен, корисниците се автентицираат на оддалечениот TACACS+ сервер, а сопственото најавување на firewall-от сè уште завршува со истек на време. Причината не е дефект во тунелот: LAN-to-LAN тунел пренесува сообраќај што одговара на неговите селектори, а управувачкиот сообраќај што ASA го генерира за себе е одделен тек со сопствена изворна адреса. Повеќето тимови го откриваат ова за време на прозорец за промени, кога единствената администраторска сметка е токму таа што не успева. Третирајте ја AAA сесијата што ја започнува ASA како тек што треба да го дизајнирате, а не како несакан ефект на поврзаност што веќе работи.

ASA е клиентот и неговиот сопствен сообраќај бара сопствен пат

Кога firewall-от контактира TACACS+ сервер, firewall-от е клиент како секој друг, освен што никој намерно не му конфигурирал рута. Неговите пакети потекнуваат од адреса на интерфејс на уредот, се генерираат локално наместо да се препраќаат, и мора да бидат рутирани, преведени и заштитени со политика исто како корисничкиот сообраќај. Тунел од локација до локација што штити корисничка подмрежа не го штити автоматски тој управувачки извор, бидејќи изборот на сообраќај се базира на адреси, а не на намера.

Запишете ја адресата што очекувате дека серверот ќе ја види. Ако не можете да ја кажете во еден ред, сè уште немате дизајн.

Интерфејсот во линијата aaa-server не е украс

На ASA, записот за домаќин aaa-server прима поврзаност со интерфејс во загради, и Cisco-виот референтен прирачник за AAA команди за домаќин го опишува како интерфејс каде што се наоѓа серверот за автентикација. Токму таа поврзаност го врзува барањето за интерфејс и за политиката што тој интерфејс ја применува. Ако го изберете според кој било интерфејс свртен кон интернет, или го оставите она што останало од последната миграција, добивате изворна адреса за која оддалечениот сервер и тунелот никогаш не биле изградени.

inside е точниот одговор само кога именуваниот интерфејс ја има адресата што вашиот дизајн има намера да ја користи како извор. На уред во филијала тоа често е така; на уред со неколку приватни сегменти можеби не.

Промената на поврзаноста значи повторно создавање на записот

Истиот референтен прирачник документира ограничување за уредување што ги фаќа луѓето при премини: промена на интерфејсот на постоечки домаќин бара отстранување и повторно создавање на записот. Конфигурација што изгледа уредена можеби не стапила на сила, и следниот обид за најава сè уште ќе излегува од старата адреса. Планирајте го тоа како бришење и додавање со копија од оригиналниот запис пред вас, а не како поправка на самото место.

Ако се дефинирани неколку сервери, променете еден и тестирајте го пред да ги допрете останатите, за да не заклучи грешка сите административни патеки одеднаш.

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

Три работи мора да се совпаднат за барањето да пристигне. Селекторите на сообраќај на тунелот, или заштитата на тунелскиот интерфејс ако користите таква, мора да го вклучуваат сопствениот извор на ASA и адресата на серверот; список на селектори изграден за кориснички подмрежи обично нема да го направи тоа. Секое NAT правило на патот мора доследно да го преведува тој извор, бидејќи серверот авторизира идентитет на мрежен уред што ја вклучува адресата што ја гледа. И повратниот пат мора да постои, што на тунел базиран на политики значи дека далечниот крај има соодветен селектор во спротивната насока.

На страната на серверот, потврдете одделно идентитетот на уредот, заедничката тајна и административната политика. TACACS+ ги држи автентикацијата, авторизацијата и сметководството како одделни операции, така што одбивање што пристигнува по завршена размена е одговор на политика, а не транспортна грешка. Ако го читате како мрежен проблем, ќе барате на погрешно место.

Држете ја тајната надвор од снимки, тикети и транскрипти додека отстранувате проблеми, и запомнете дека изворната адреса што серверот ја запишува е таа што вашиот дизајн мора да ја објасни.

Направете ја промената без да се заклучите

Користете конзола или независна управувачка патека додека ја менувате оддалечената административна автентикација, и држете одобрена локална резерва додека новата патека не пренесе вистинска најава. Потоа валидирајте тесно: еден сервер, еден уред, една успешна автентикација со изворната адреса забележана на двата краја.

Запишете го текот на негова сопствена страница: изворен интерфејс и адреса, оддалечен сервер, заштитена патека и лицето што ја поседува политиката за авторизација. Тогаш подоцнежна промена на интерфејс или тунел може да се оцени без погодување кој од двата тек ја засега.