Hvorfor ASA-ens egne TACACS+-forespørsler hopper over filialens VPN-tunnel

Filialtunnelen er oppe, brukerne autentiserer seg mot den eksterne TACACS+-serveren, og selve innloggingen på brannmuren timer fortsatt ut. Årsaken er ikke en feil i tunnelen: en LAN-to-LAN-tunnel bærer trafikk som matcher selektorene dens, og administrasjonstrafikken ASA genererer om seg selv er en egen strøm med sin egen kildeadresse. De fleste team oppdager dette i et endringsvindu, når den eneste administratorkontoen er den som feiler. Behandle AAA-økten ASA starter som en strøm du må designe, ikke som en bivirkning av en tilkobling som allerede virker.

ASA-en er klienten, og dens egen trafikk trenger sin egen vei

Når brannmuren kontakter en TACACS+-server, er brannmuren en klient som alle andre, bortsett fra at ingen bevisst har konfigurert en rute for den. Pakkene dens kommer fra en grensesnittadresse på enheten, de genereres lokalt i stedet for å videresendes, og de må rutes, oversettes og beskyttes av policy akkurat som brukertrafikk. En site-til-site-tunnel som beskytter et brukersubnett beskytter ikke automatisk den administrasjonskilden, fordi trafikkvalg er basert på adresser og ikke på hensikt.

Skriv ned adressen du forventer at serveren skal se. Hvis du ikke kan si den på én linje, har du ennå ikke et design.

Grensesnittet i aaa-server-linjen er ikke pynt

På ASA-en tar aaa-server-vertsoppføringen en grensesnittkobling i parentes, og Ciscos kommandoreferanse for AAA-verter beskriver den som grensesnittet der autentiseringsserveren ligger. Det er den koblingen som binder forespørselen til et grensesnitt og til policyen det grensesnittet anvender. Velger man den etter grensesnittet som vender mot internett, eller lar stå det som var igjen fra forrige migrering, får man en kildeadresse som den eksterne serveren og tunnelen aldri ble bygget for.

inside er bare riktig svar når det navngitte grensesnittet har adressen designet ditt vil bruke som kilde. På en filialenhet er det ofte slik; på en enhet med flere private segmenter kanskje ikke.

Å endre koblingen betyr å gjenskape oppføringen

Den samme kommandoreferansen dokumenterer en redigeringsbegrensning som fanger folk under overganger: å endre grensesnittet på en eksisterende vert krever at vertsoppføringen fjernes og gjenskapes. En konfigurasjon som ser redigert ut har kanskje ikke trådt i kraft, og neste innloggingsforsøk går fortsatt ut fra den gamle adressen. Planlegg det som sletting og tillegg med en kopi av den opprinnelige oppføringen foran deg, ikke som en justering på stedet.

Hvis flere servere er definert, endre én og test den før du rører de andre, slik at en feil ikke låser alle administrative veier samtidig.

Kontroller selektorer, oversettelse og returvei sammen

Tre ting må stemme for at forespørselen skal komme frem. Tunnelens trafikkselektorer, eller tunnelgrensesnittbeskyttelsen hvis du bruker en, må omfatte ASA-ens egen kilde og serverens adresse; en selektorliste bygget for brukersubnett gjør det vanligvis ikke. Enhver NAT-regel på veien må oversette den kilden konsistent, fordi serveren autoriserer en nettverksenhetsidentitet som inkluderer adressen den ser. Og returveien må finnes, noe som på en policybasert tunnel betyr at den andre enden har en tilsvarende selektor i motsatt retning.

På serversiden bekrefter du enhetsidentiteten, den delte hemmeligheten og administrasjonspolicyen hver for seg. TACACS+ holder autentisering, autorisasjon og regnskap som adskilte operasjoner, så en avvisning som kommer etter en fullført utveksling er et policysvar, ikke en transportfeil. Leser du den som et nettverksproblem, leter du på feil sted.

Hold hemmeligheten utenfor opptak, saker og transkripsjoner mens du feilsøker, og husk at kildeadressen serveren logger er den designet ditt må forklare.

Gjør endringen uten å låse deg selv ute

Bruk en konsoll eller en uavhengig administrasjonsvei mens du endrer ekstern administrativ autentisering, og hold en godkjent lokal fallback til den nye veien har båret en reell innlogging. Valider deretter smalt: én server, én enhet, én vellykket autentisering med kildeadressen observert i begge ender.

Notér strømmen på sin egen side: opprinnelsesgrensesnitt og -adresse, ekstern server, beskyttet vei og personen som eier autorisasjonspolicyen. Da kan en senere grensesnitt- eller tunnelendring vurderes uten å gjette hvilken av de to strømmene den påvirker.