Waarom TACACS+-verzoeken van de ASA je branch-VPN-tunnel overslaan

De branchtunnel staat, gebruikers authenticeren bij de externe TACACS+-server, en de eigen login van de firewall loopt nog steeds in een timeout. De oorzaak is geen fout in de tunnel: een LAN-to-LAN-tunnel draagt verkeer dat bij zijn selectors past, en het beheerverkeer dat de ASA over zichzelf genereert is een aparte stroom met een eigen bronadres. De meeste teams ontdekken dit tijdens een wijzigingsvenster, wanneer het enige beheerdersaccount degene is die faalt. Behandel de AAA-sessie die de ASA start als een stroom die je moet ontwerpen, niet als een bijwerking van connectiviteit die al werkt.

De ASA is de client, en zijn eigen verkeer heeft zijn eigen pad nodig

Wanneer de firewall een TACACS+-server benadert, is de firewall een client als elke andere, behalve dat niemand er bewust een route voor heeft geconfigureerd. Zijn pakketten komen van een interfaceadres op het apparaat, ze worden lokaal gegenereerd in plaats van doorgestuurd, en ze moeten worden gerouteerd, vertaald en door beleid beschermd, precies zoals gebruikersverkeer. Een site-naar-site-tunnel die een gebruikerssubnet beschermt, beschermt die beheerbron niet automatisch, omdat verkeersselectie op adressen is gebaseerd en niet op bedoeling.

Schrijf het adres op dat je verwacht dat de server ziet. Als je het niet in één regel kunt zeggen, heb je nog geen ontwerp.

De interface in de aaa-server-regel is geen versiering

Op de ASA neemt de host-entry aaa-server een interface-koppeling tussen haakjes aan, en Cisco's opdrachtreferentie voor AAA-hosts beschrijft die als de interface waar de authenticatieserver zich bevindt. Juist die koppeling verbindt het verzoek met een interface en met het beleid dat die interface toepast. Kies je hem op basis van welke interface dan ook naar het internet kijkt, of laat je staan wat er van de laatste migratie over was, dan ontstaat een bronadres waarvoor de externe server en de tunnel nooit zijn gebouwd.

inside is alleen het juiste antwoord wanneer de genoemde interface het adres heeft dat je ontwerp als bron wil gebruiken. Op een branchapparaat is dat vaak zo; op een apparaat met meerdere privésegmenten misschien niet.

De koppeling wijzigen betekent de entry opnieuw aanmaken

Dezelfde opdrachtreferentie documenteert een bewerkingsbeperking die mensen bij overgangen laat struikelen: de interface op een bestaande host wijzigen vereist dat de host-entry wordt verwijderd en opnieuw aangemaakt. Een configuratie die bewerkt lijkt, is mogelijk niet van kracht geworden, en de volgende loginpoging vertrekt nog steeds vanaf het oude adres. Plan dat als verwijderen en toevoegen met een kopie van de oorspronkelijke entry voor je, niet als een aanpassing ter plaatse.

Zijn er meerdere servers gedefinieerd, wijzig er dan één en test die voordat je de rest aanraakt, zodat één fout niet alle beheerpaden tegelijk op slot zet.

Controleer selectors, vertaling en retourpad samen

Drie dingen moeten kloppen wil het verzoek aankomen. De verkeersselectors van de tunnel, of de tunnel-interfacebescherming als je die gebruikt, moeten de eigen bron van de ASA en het adres van de server bevatten; een selectorlijst die voor gebruikerssubnetten is gebouwd, doet dat meestal niet. Elke NAT-regel op het pad moet die bron consistent vertalen, omdat de server een netwerkapparaatidentiteit autoriseert die het adres omvat dat hij ziet. En het retourpad moet bestaan, wat bij een op beleid gebaseerde tunnel betekent dat de andere kant een passende selector in de tegengestelde richting heeft.

Controleer aan de serverkant de apparaatidentiteit, het gedeelde geheim en het beheerbeleid apart. TACACS+ houdt authenticatie, autorisatie en accounting als afzonderlijke bewerkingen, dus een weigering die na een voltooide uitwisseling komt is een beleidsantwoord, geen transportstoring. Lees je die als een netwerkprobleem, dan zoek je op de verkeerde plek.

Houd het geheim tijdens het debuggen buiten captures, tickets en transcripties, en onthoud dat het bronadres dat de server logt het adres is dat je ontwerp moet verklaren.

Voer de wijziging uit zonder jezelf buiten te sluiten

Gebruik een console of een onafhankelijk beheerpad terwijl je de externe beheerauthenticatie wijzigt, en houd een goedgekeurde lokale terugvaloptie tot het nieuwe pad een echte login heeft gedragen. Valideer daarna smal: één server, één apparaat, één geslaagde authenticatie met het bronadres aan beide kanten waargenomen.

Leg de stroom vast op een eigen pagina: oorsprongsinterface en -adres, externe server, beschermd pad en de persoon die het autorisatiebeleid bezit. Een latere interface- of tunnelwijziging kan dan worden beoordeeld zonder te raden welke van de twee stromen die raakt.