Tilføj en anden kryptomap-post for det samme adressepar, peg den på en anden peer, og du har skrevet en failover-plan. Det er myten, og den overlever, fordi den ligner enhver anden ordnet liste, du har konfigureret. Rækkefølgen i en kryptomap afgør, hvilken post der gør krav på et nyt flow, ikke hvilken post der overtager, når en peer holder op med at svare. Intet på den liste overvåger den fjerne ende, så den anden post sidder bare der uden at gøre krav på noget som helst.

Myten: rækkefølge betyder fallback

En ordnet liste med to poster og én fælles definition føles som primær og sekundær. Ligheden slutter ved syntaksen. Ciscos ASA-dokumentation beskriver kryptomappen som den policymodel, der matcher beskyttet trafik og navngiver peer-arrangementet for den, og matchningen sker mod den post, der gør krav på flowet først. Tilgængeligheden af en fjern peer er ikke en del af den vurdering.

Det, du har bygget, er en politik, der aldrig vil blive konsulteret for det flow, plus en kommentar i en ændringsjournal, der hævder redundans.

Rækkefølgen gør krav på flowet, og kun én gang

Hver post indeholder en adgangskontrolliste eller en definition af et beskyttet flow, og hver ny udgående pakke sammenlignes med disse definitioner i rækkefølge. Den første post, hvis definition matcher, ejer flowet og dens peer. En anden post med en identisk definition får aldrig en tur, fordi den første allerede matchede; en anden post med en snævrere definition betjener kun flows, som den første ikke gjorde krav på.

Den adfærd er nyttig, når du bevidst skærer undtagelser ud af en bred politik, og den er ubrugelig som failover-mekanisme. Kontroller, hvad der faktisk skete med show crypto map og show crypto ipsec sa peer, og spor derefter en syntetisk pakke gennem den vej, du tror, den tager. Sporingen vil navngive den post, der gjorde krav på den, og det er det eneste svar, der betyder noget.

Rutevalg og policy-ejerskab er separate beslutninger

En routingtabel svarer på, hvor pakken videresendes. Kryptopolitikken svarer på, hvilken beskyttelse og hvilken peer der gælder for den valgte trafik. Duplikering af et kilde- og destinationspar under en anden peer ændrer den anden beslutning og lader den første være urørt, så svar kan stadig følge den gamle gateway, mens den udgående pakke tager den nye peer. Den asymmetri producerer en tunnel, der rapporterer oppe og ikke passerer noget.

Hold også kontrakten gensidig med den fjerne ende: accepteret identitet, beskyttede adresseområder, en returrute for de interessante præfikser og tilladelse til tjenesten. Et alternativt udgående valg, som den anden side ikke forventer, er ikke en alternativ vej, det er halvdelen af en.

Hvad en rigtig alternativ vej kræver

Vælg en mekanisme, der er designet til opgaven: en understøttet gruppe af peer-kandidater, en routet tunnel med en flydende statisk eller dynamisk routing-tilstødning hen over den, eller hvilket som helst redundansdesign din platform dokumenterer for den tjeneste. Skriv derefter ned, hvilken komponent der registrerer fejlen, og hvilken komponent der vælger alternativet, for det er to forskellige funktioner og ofte to forskellige teams.

Adresseoversættelse kan også give et sted en anden præsenteret adresse, men den ændrer samtidig selectors, logning og kildebaserede adgangsregler. Behandl det som et udtrykkeligt krav i stedet for som en omvej for to tvetydige poster.

Test tre tilstande, ikke én

Konfigurationen er først færdig, når den har et forsvarligt svar på normal drift, på tilstanden med fejlet primær og på tilbagevenden til primær. Test alle tre og noter, hvilken politikpost og hvilken peer der betjente hver af dem. En test, der stopper efter den første tilstand, beviser, at designet virker, når intet er galt, og det er den tilstand, du ikke behøvede at kontrollere.

Skeln også mellem konfigureret overlapning og den legitime sameksistens af gamle og nye associationer under en nøglefornyelse. Flere aktive SA'er er normale og midlertidige; to poster, der kæmper om ét flow, er permanente og usynlige.

Relaterede artikler