De ce cererile TACACS+ ale ASA ocolesc tunelul VPN al sucursalei tale

Tunelul sucursalei este activ, utilizatorii se autentifică la serverul TACACS+ la distanță, iar autentificarea firewall-ului însuși expiră în continuare. Cauza nu este un defect al tunelului: un tunel LAN-to-LAN transportă traficul care corespunde selectoarelor sale, iar traficul de administrare pe care ASA îl generează despre sine este un flux separat, cu propria adresă sursă. Majoritatea echipelor descoperă acest lucru în timpul unei ferestre de modificări, când singurul cont de administrator este cel care eșuează. Tratați sesiunea AAA inițiată de ASA ca pe un flux pe care trebuie să-l proiectați, nu ca pe un efect secundar al unei conectivități care funcționează deja.

ASA este clientul, iar propriul său trafic are nevoie de propria cale

Când firewall-ul contactează un server TACACS+, firewall-ul este un client ca oricare altul, doar că nimeni nu i-a configurat intenționat o rută. Pachetele sale provin dintr-o adresă de interfață a echipamentului, sunt generate local în loc să fie redirecționate, și trebuie rutate, traduse și protejate prin politică exact ca traficul utilizatorilor. Un tunel de la site la site care protejează o subrețea de utilizatori nu protejează automat acea sursă de administrare, pentru că selecția traficului se bazează pe adrese, nu pe intenție.

Notați adresa pe care vă așteptați să o vadă serverul. Dacă nu o puteți spune într-o singură linie, încă nu aveți un proiect.

Interfața din linia aaa-server nu este decor

Pe ASA, intrarea de host aaa-server preia o asociere de interfață între paranteze, iar referința comenzilor de host AAA de la Cisco o descrie ca interfața pe care se află serverul de autentificare. Această asociere este cea care leagă cererea de o interfață și de politica pe care o aplică acea interfață. Alegerea după orice interfață orientată spre internet, sau lăsarea a ceea ce a rămas de la ultima migrare, produce o adresă sursă pentru care serverul la distanță și tunelul nu au fost niciodată construite.

inside este răspunsul corect doar când interfața numită deține adresa pe care proiectul dvs. intenționează să o folosească drept sursă. Pe un echipament de sucursală este adesea cazul; pe un echipament cu mai multe segmente private poate să nu fie.

Schimbarea asocierii înseamnă recrearea intrării

Aceeași referință de comenzi documentează o restricție de editare care prinde oamenii în timpul tranzițiilor: schimbarea interfeței pe un host existent cere eliminarea și recrearea intrării de host. O configurație care pare editată poate să nu fi intrat în vigoare, iar următoarea încercare de autentificare va pleca tot din adresa veche. Planificați-o ca ștergere și adăugare, cu o copie a intrării originale în față, nu ca o ajustare la fața locului.

Dacă sunt definite mai multe servere, modificați unul și testați-l înainte de a le atinge pe celelalte, ca o greșeală să nu blocheze toate căile administrative deodată.

Verificați selectoarele, traducerea și calea de întoarcere împreună

Trei lucruri trebuie să coincidă pentru ca cererea să ajungă. Selectoarele de trafic ale tunelului, sau protecția interfeței de tunel dacă folosiți una, trebuie să includă sursa proprie a ASA și adresa serverului; o listă de selectoare construită pentru subrețele de utilizatori de obicei nu va face asta. Orice regulă NAT de pe cale trebuie să traducă acea sursă în mod consecvent, pentru că serverul autorizează o identitate de echipament de rețea care include adresa pe care o vede. Iar calea de întoarcere trebuie să existe, ceea ce într-un tunel bazat pe politici înseamnă că celălalt capăt are un selector corespunzător în direcția opusă.

Pe partea de server, confirmați separat identitatea echipamentului, secretul partajat și politica administrativă. TACACS+ păstrează autentificarea, autorizarea și contabilitatea ca operații distincte, așa că un refuz care sosește după un schimb finalizat este un răspuns de politică, nu o defecțiune de transport. Citirea lui ca problemă de rețea vă trimite să căutați în locul greșit.

Țineți secretul în afara capturilor, tichetelor și transcrierilor în timp ce depanați, și amintiți-vă că adresa sursă pe care serverul o înregistrează este cea pe care proiectul dvs. trebuie să o explice.

Faceți modificarea fără să vă blocați afară

Folosiți o consolă sau o cale de administrare independentă în timp ce schimbați autentificarea administrativă la distanță, și păstrați o soluție locală de rezervă aprobată până când noua cale a transportat o autentificare reală. Apoi validați îngust: un server, un echipament, o autentificare reușită cu adresa sursă observată la ambele capete.

Înregistrați fluxul pe pagina lui: interfața și adresa de origine, serverul la distanță, calea protejată și persoana care deține politica de autorizare. Atunci o modificare ulterioară de interfață sau de tunel poate fi evaluată fără a ghici care dintre cele două fluxuri este afectat.