Varför ASA:ns egna TACACS+-förfrågningar går förbi filialens VPN-tunnel

Filialtunneln är uppe, användarna autentiserar mot den externa TACACS+-servern, och brandväggens egen inloggning tar fortfarande timeout. Orsaken är inte ett fel i tunneln: en LAN-to-LAN-tunnel bär trafik som matchar dess selektorer, och den hanteringstrafik som ASA genererar om sig själv är ett eget flöde med egen källadress. De flesta team upptäcker detta under ett ändringsfönster, när det enda administratörskontot är det som misslyckas. Behandla AAA-sessionen som ASA startar som ett flöde du måste designa, inte som en bieffekt av en anslutning som redan fungerar.

ASA:n är klienten, och dess egen trafik behöver sin egen väg

När brandväggen kontaktar en TACACS+-server är brandväggen en klient som alla andra, förutom att ingen medvetet har konfigurerat en route för den. Dess paket utgår från en gränssnittsadress på enheten, de genereras lokalt i stället för att vidarebefordras, och de måste routas, översättas och skyddas av policy precis som användartrafik. En site-till-site-tunnel som skyddar ett användarsubnät skyddar inte automatiskt den hanteringskällan, eftersom trafikvalet bygger på adresser och inte på avsikt.

Skriv ned den adress du förväntar dig att servern ska se. Om du inte kan säga den på en rad har du ännu ingen design.

Gränssnittet i aaa-server-raden är inte dekoration

På ASA:n tar aaa-server-värdposten en gränssnittskoppling inom parentes, och Ciscos kommandoreferens för AAA-värdar beskriver den som det gränssnitt där autentiseringsservern ligger. Det är den kopplingen som binder förfrågan till ett gränssnitt och till den policy som gränssnittet tillämpar. Väljer man den efter vilket gränssnitt som helst som vetter mot internet, eller låter stå det som fanns kvar från den senaste migreringen, får man en källadress som den externa servern och tunneln aldrig byggdes för.

inside är bara rätt svar när det namngivna gränssnittet har den adress som din design tänker använda som källa. På en filialenhet är det ofta så; på en enhet med flera privata segment kanske inte.

Att ändra kopplingen innebär att posten måste skapas om

Samma kommandoreferens dokumenterar en redigeringsbegränsning som fångar folk vid övergångar: att ändra gränssnittet på en befintlig värd kräver att värdposten tas bort och skapas om. En konfiguration som ser redigerad ut har kanske inte trätt i kraft, och nästa inloggningsförsök går fortfarande ut från den gamla adressen. Planera det som borttagning och tillägg med en kopia av den ursprungliga posten framför dig, inte som en justering på plats.

Om flera servrar är definierade, ändra en och testa den innan du rör de övriga, så att ett misstag inte låser alla administrativa vägar på en gång.

Kontrollera selektorer, översättning och returväg tillsammans

Tre saker måste stämma för att förfrågan ska komma fram. Tunnelns trafikselektorer, eller tunnelgränssnittsskyddet om du använder ett sådant, måste omfatta ASA:ns egen källa och serverns adress; en selektorlista byggd för användarsubnät gör det vanligtvis inte. Varje NAT-regel på vägen måste översätta den källan konsekvent, eftersom servern auktoriserar en nätverksenhetsidentitet som inkluderar adressen den ser. Och returvägen måste finnas, vilket på en policybaserad tunnel innebär att den andra änden har en matchande selektor i motsatt riktning.

På serversidan bekräftar du enhetsidentiteten, den delade hemligheten och hanteringspolicyn var för sig. TACACS+ håller autentisering, auktorisering och redovisning som separata operationer, så ett avslag som kommer efter ett avslutat utbyte är ett policysvar, inte ett transportfel. Läser du det som ett nätverksproblem letar du på fel ställe.

Håll hemligheten utanför fångster, ärenden och transkriptioner medan du felsöker, och kom ihåg att den källadress servern loggar är den som din design måste förklara.

Gör ändringen utan att låsa ut dig själv

Använd en konsol eller en oberoende hanteringsväg medan du ändrar den externa administrativa autentiseringen, och håll en godkänd lokal reservväg tills den nya vägen har burit en riktig inloggning. Validera sedan snävt: en server, en enhet, en lyckad autentisering med källadressen observerad i båda ändar.

Anteckna flödet på en egen sida: ursprungsgränssnitt och -adress, extern server, skyddad väg och personen som äger auktoriseringspolicyn. Då kan en senare gränssnitts- eller tunneländring bedömas utan att gissa vilket av de två flödena den påverkar.