Hvorfor ASA'ens TACACS+-anmodninger springer din filials VPN-tunnel over

Filialtunnelen er oppe, brugerne godkender mod den eksterne TACACS+-server, og firewallens eget login timer stadig ud. Årsagen er ikke en fejl i tunnelen: en LAN-to-LAN-tunnel bærer trafik, der matcher dens selektorer, og den administrationstrafik, som ASA'en genererer om sig selv, er en separat strøm med sin egen kildeadresse. De fleste teams opdager det under et ændringsvindue, hvor den eneste administratorkonto er den, der fejler. Behandl den AAA-session, ASA'en starter, som en strøm, du skal designe, ikke som en bivirkning af en forbindelse, der allerede virker.

ASA'en er klienten, og dens egen trafik kræver sin egen vej

Når firewallen kontakter en TACACS+-server, er firewallen en klient som enhver anden, bortset fra at ingen bevidst har konfigureret en rute til den. Dens pakker udgår fra en interface-adresse på enheden, de genereres lokalt i stedet for at blive videresendt, og de skal rutest, oversættes og beskyttes af politik ligesom brugertrafik. En site-to-site-tunnel, der beskytter et brugersubnet, beskytter ikke automatisk den administrationskilde, fordi trafikvalg bygger på adresser og ikke på hensigt.

Skriv den adresse ned, du forventer, at serveren ser. Hvis du ikke kan sige den på én linje, har du endnu ikke et design.

Interfacet i aaa-server-linjen er ikke pynt

På ASA'en tager aaa-server-hostposten en interface-tilknytning i parentes, og Ciscos kommandoreference for AAA-hosts beskriver den som det interface, hvor godkendelsesserveren ligger. Det er den tilknytning, der binder anmodningen til et interface og til den politik, det interface anvender. Vælger man den efter det interface, der vender mod internettet, eller lader man det stå, der var fra den sidste migrering, får man en kildeadresse, som den eksterne server og tunnelen aldrig blev bygget til.

inside er kun det rigtige svar, når det navngivne interface har den adresse, dit design vil bruge som kilde. På en filialenhed er det ofte tilfældet; på en enhed med flere private segmenter måske ikke.

Ændring af tilknytningen betyder, at posten skal genskabes

Den samme kommandoreference dokumenterer en redigeringsbegrænsning, som fanger folk under overgange: at ændre interfacet på en eksisterende host kræver, at hostposten fjernes og genskabes. En konfiguration, der ser redigeret ud, har måske ikke fået virkning, og det næste loginforsøg vil stadig gå ud fra den gamle adresse. Planlæg det som en slet-og-tilføj med en kopi af den oprindelige post foran dig, ikke som en rettelse på stedet.

Hvis der er defineret flere servere, så ændr én og test den, før du rører resten, så en fejl ikke låser alle administrative veje på én gang.

Kontrollér selektorer, oversættelse og returvej sammen

Tre ting skal stemme, for at anmodningen når frem. Tunnellens trafikselektorer, eller tunnel-interface-beskyttelsen hvis du kører en, skal omfatte ASA'ens egen kilde og serverens adresse; en selektorliste bygget til brugersubnet gør det normalt ikke. Enhver NAT-regel på vejen skal oversætte den kilde konsistent, fordi serveren autoriserer en netværksenhedsidentitet, der omfatter den adresse, den ser. Og returvejen skal findes, hvilket på en politikbaseret tunnel betyder, at den fjerne ende har en matchende selektor i den anden retning.

På serversiden skal du bekræfte enhedsidentiteten, den delte hemmelighed og den administrative politik hver for sig. TACACS+ holder godkendelse, autorisation og regnskab som adskilte operationer, så en afvisning, der kommer efter en fuldført udveksling, er et politiksvar, ikke en transportfejl. Læser du den som et netværksproblem, leder du det forkerte sted.

Hold hemmeligheden ude af optagelser, tickets og transskriptioner, mens du fejlretter, og husk, at den kildeadresse, serveren logger, er den, dit design skal forklare.

Lav ændringen uden at låse dig selv ude

Brug en konsol eller en uafhængig administrationsvej, mens du ændrer ekstern administrativ godkendelse, og hold en godkendt lokal fallback, indtil den nye vej har båret et rigtigt login. Validér derefter snævert: én server, én enhed, én vellykket godkendelse med kildeadressen observeret i begge ender.

Notér strømmen på sin egen side: oprindelsesinterface og -adresse, ekstern server, beskyttet vej og den person, der ejer autorisationspolitikken. Så kan en senere interface- eller tunnelændring vurderes uden at gætte, hvilken af de to strømme den påvirker.