Kvifor TACACS+-førespurnadene til ASA hoppar over VPN-tunnelen til filialen

Filialtunnelen er oppe, brukarane autentiserer seg mot den eksterne TACACS+-tenaren, og sjølve innlogginga på brannmuren går framleis ut på tid. Årsaka er ikkje ein feil i tunnelen: ein LAN-to-LAN-tunnel ber trafikk som passar med selektorane sine, og administrasjonstrafikken som ASA genererer om seg sjølv er ein eigen straum med si eiga kjeldeadresse. Dei fleste team oppdagar dette i eit endringsvindauge, når den einaste administratorkontoen er den som feilar. Handsame AAA-økta som ASA startar som ein straum du må designe, ikkje som ein bieffekt av ei tilkopling som allereie verkar.

ASA-en er klienten, og eigen trafikk treng eigen veg

Når brannmuren kontaktar ein TACACS+-tenar, er brannmuren ein klient som alle andre, bortsett frå at ingen med vilje har konfigurert ein rute for han. Pakkane hans kjem frå ei grensesnittadresse på eininga, dei blir genererte lokalt i staden for videresende, og dei må rutast, omsetjast og vernast av policy akkurat som brukartrafikk. Ein site-til-site-tunnel som vernar eit brukarsubnett vernar ikkje automatisk den administrasjonskjelda, fordi trafikkval er basert på adresser og ikkje på hensikt.

Skriv ned adressa du ventar at tenaren skal sjå. Viss du ikkje kan seie ho på éi linje, har du enno ikkje eit design.

Grensesnittet i aaa-server-linja er ikkje pynt

På ASA-en tek aaa-server-vertoppføringa ei grensesnittkopling i parentes, og Ciscos kommandoreferanse for AAA-vertar skildrar ho som grensesnittet der autentiseringstenaren ligg. Det er den koplinga som bind førespurnaden til eit grensesnitt og til policyen som grensesnittet brukar. Vel ein ho etter grensesnittet som vender mot internett, eller lèt stå det som var att frå førre migrering, får ein ei kjeldeadresse som den eksterne tenaren og tunnelen aldri vart bygde for.

inside er berre rett svar når det namngjetne grensesnittet har adressa designet ditt vil bruke som kjelde. På ei filialeining er det ofte slik; på ei eining med fleire private segment kanskje ikkje.

Å endre koplinga tyder å gjenskape oppføringa

Den same kommandoreferansen dokumenterer ei redigeringsavgrensing som fangar folk under overgangar: å endre grensesnittet på ein eksisterande vert krev at vertsoppføringa blir fjerna og gjenskapt. Ein konfigurasjon som ser redigert ut er kanskje ikkje sett i kraft, og neste innloggingsforsøk går framleis ut frå den gamle adressa. Planlegg det som sletting og tillegg med ein kopi av den opphavlege oppføringa føre deg, ikkje som ei justering på staden.

Viss fleire tenarar er definerte, endre éin og test han før du rører dei andre, slik at ein feil ikkje låser alle administrative vegar på ein gong.

Kontroller selektorar, omsetjing og returveg saman

Tre ting må stemme for at førespurnaden skal kome fram. Trafikkselektorane til tunnelen, eller tunnelgrensesnittvernet viss du brukar eit, må omfatte den eigne kjelda til ASA og adressa til tenaren; ei selektorliste bygd for brukarsubnett gjer det vanlegvis ikkje. Kvar NAT-regel på vegen må omsetje den kjelda konsekvent, fordi tenaren autoriserer ein nettverkseiningidentitet som omfattar adressa han ser. Og returvegen må finnast, noko som på ein policybasert tunnel tyder at den andre sida har ein samsvarande selektor i motsett retning.

På tenarsida stadfestar du einingidentiteten, den delte løyndomen og administrasjonspolicyen kvar for seg. TACACS+ held autentisering, autorisasjon og rekneskap som skilde operasjonar, så ei avvising som kjem etter ein fullført utveksling er eit policysvar, ikkje ein transportfeil. Les du ho som eit nettverksproblem, leitar du på feil stad.

Hald løyndomen utanfor opptak, saker og transkripsjonar medan du feilsøkjer, og hugs at kjeldeadressa tenaren loggar er den designet ditt må forklare.

Gjer endringa utan å låse deg sjølv ute

Bruk ein konsoll eller ein uavhengig administrasjonsveg medan du endrar ekstern administrativ autentisering, og hald ein godkjend lokal reserveveg til den nye vegen har bore ei reell innlogging. Valider deretter smalt: éin tenar, éi eining, éi vellukka autentisering med kjeldeadressa observert i båe endar.

Før straumen på si eiga side: opphavsgrensesnitt og -adresse, ekstern tenar, verna veg og personen som eig autorisasjonspolicyen. Då kan ei seinare grensesnitt- eller tunnelendring vurderast utan å gjete kva av dei to straumane ho råkar.