Twee cryptomaps, één flow: de latere vermelding is geen back-up

Voeg een tweede cryptomap-vermelding toe voor hetzelfde adrespaar, wijs die naar een andere peer, en je hebt een failover-plan geschreven. Dat is de mythe, en hij overleeft omdat hij lijkt op elke andere geordende lijst die je hebt geconfigureerd. De volgorde in een cryptomap bepaalt welke vermelding een nieuwe flow claimt, niet welke vermelding overneemt wanneer een peer stopt met antwoorden. Niets in die lijst bewaakt de verre kant, dus de tweede vermelding zit daar zonder iets te claimen.

De mythe: volgorde betekent terugval

Een geordende lijst met twee vermeldingen en één gedeelde definitie voelt als primair en secundair. De gelijkenis eindigt bij de syntaxis. De ASA-documentatie van Cisco beschrijft de cryptomap als het beleidsmodel dat beschermd verkeer koppelt en de peer-indeling daarvoor benoemt, en de koppeling gebeurt tegen de vermelding die de flow als eerste claimt. De beschikbaarheid van een externe peer maakt geen deel uit van die beoordeling.

Wat je hebt gebouwd is een beleid dat voor die flow nooit wordt geraadpleegd, plus een opmerking in een wijzigingsrecord die redundantie beweert.

De volgorde claimt de flow, en slechts één keer

Elke vermelding bevat een toegangscontrolelijst of een definitie van een beschermde flow, en elk nieuw uitgaand pakket wordt in volgorde met die definities vergeleken. De eerste vermelding waarvan de definitie overeenkomt, bezit de flow en zijn peer. Een tweede vermelding met een identieke definitie krijgt nooit een beurt, omdat de eerste al overeenkwam; een tweede vermelding met een nauwere definitie bedient alleen flows die de eerste niet claimde.

Dat gedrag is nuttig wanneer je bewust uitzonderingen uit een breed beleid snijdt, en het is nutteloos als failover-mechanisme. Controleer wat er werkelijk is gebeurd met show crypto map en show crypto ipsec sa peer, en volg dan een synthetisch pakket over het pad dat het volgens jou neemt. De tracering noemt de vermelding die het claimde, en dat is het enige antwoord dat ertoe doet.

Routeselectie en beleidseigendom zijn afzonderlijke beslissingen

Een routingtabel beantwoordt waar het pakket naartoe wordt doorgestuurd. Het cryptobeleid beantwoordt welke bescherming en welke peer gelden voor het geselecteerde verkeer. Het dupliceren van een bron- en bestemmingspaar onder een andere peer verandert de tweede beslissing en laat de eerste ongemoeid, dus antwoorden kunnen nog steeds de oude gateway volgen terwijl het uitgaande pakket de nieuwe peer neemt. Die asymmetrie levert een tunnel op die meldt dat hij actief is en niets doorlaat.

Houd ook het contract met de verre kant wederkerig: geaccepteerde identiteit, beschermde adresbereiken, een retourroute voor de interessante prefixen en toestemming voor de dienst. Een alternatieve uitgaande keuze die de andere kant niet verwacht, is geen alternatief pad, het is de helft ervan.

Wat een echt alternatief pad nodig heeft

Kies een mechanisme dat voor de taak is ontworpen: een ondersteunde groep peer-kandidaten, een gerouteerde tunnel met een zwevende statische of dynamische routing-buurnabijheid eroverheen, of welk redundantieontwerp je platform voor die dienst ook documenteert. Schrijf dan op welke component de storing detecteert en welke component het alternatief selecteert, want dat zijn twee verschillende functies en vaak twee verschillende teams.

Adresvertaling kan een site ook een tweede gepresenteerd adres geven, maar het verandert tegelijk selectors, logging en op de bron gebaseerde toegangsregels. Behandel dat als een expliciete eis en niet als een omweg voor twee dubbelzinnige vermeldingen.

Test drie toestanden, niet één

De configuratie is pas klaar wanneer ze een verdedigbaar antwoord heeft voor normaal bedrijf, voor de toestand van de uitgevallen primaire en voor de terugkeer naar de primaire. Test alle drie en noteer welke beleidsvermelding en welke peer elk ervan heeft bediend. Een test die na de eerste toestand stopt, bewijst dat het ontwerp werkt wanneer er niets mis is, en dat is de toestand die je niet hoefde te controleren.

Onderscheid ook geconfigureerde overlap van het legitieme naast elkaar bestaan van oude en nieuwe associaties tijdens een sleutelvernieuwing. Meerdere actieve SA's zijn normaal en tijdelijk; twee vermeldingen die om één flow vechten, zijn permanent en onzichtbaar.