To kryptokart, én flyt: den senere oppføringen er ikke en sikkerhetskopi
Et duplikat adressepar under en annen peer er ikke failover. Finn ut hvilken kryptokart-oppføring som gjør krav på flyten, og hvilken komponent som faktisk bytter den.
Legg til en andre kryptokart-oppføring for samme adressepar, pek den mot en annen peer, og du har skrevet en failover-plan. Det er myten, og den overlever fordi den ser ut som enhver annen ordnet liste du har konfigurert. Rekkefølgen i et kryptokart avgjør hvilken oppføring som gjør krav på en ny flyt, ikke hvilken oppføring som tar over når en peer slutter å svare. Ingenting i den listen overvåker den fjerne enden, så den andre oppføringen sitter bare der uten å gjøre krav på noe som helst.
Myten: rekkefølge betyr reserve
En ordnet liste med to oppføringer og én delt definisjon føles som primær og sekundær. Likheten slutter ved syntaksen. ASAs dokumentasjon fra Cisco beskriver kryptokartet som policymodellen som matcher beskyttet trafikk og navngir peer-oppsettet for den, og matchingen skjer mot oppføringen som gjør krav på flyten først. Tilgjengeligheten til en ekstern peer er ikke en del av den vurderingen.
Det du har bygget, er en policy som aldri vil bli konsultert for den flyten, pluss en kommentar i en endringslogg som hevder redundans.
Rekkefølgen gjør krav på flyten, og bare én gang
Hver oppføring holder en tilgangskontrolliste eller en definisjon av en beskyttet flyt, og hver ny utgående pakke sammenlignes med disse definisjonene i rekkefølge. Den første oppføringen der definisjonen stemmer, eier flyten og peeren sin. En andre oppføring med identisk definisjon får aldri en tur, fordi den første allerede stemte; en andre oppføring med en snevrere definisjon betjener bare flyter den første ikke gjorde krav på.
Den atferden er nyttig når du bevisst skjærer unntak ut av en bred policy, og den er ubrukelig som failover-mekanisme. Sjekk hva som faktisk skjedde med show crypto map og show crypto ipsec sa peer, og spor deretter en syntetisk pakke gjennom veien du tror den tar. Sporet vil navngi oppføringen som gjorde krav på den, og det er det eneste svaret som betyr noe.
Rutevalg og policy-eierskap er separate beslutninger
En rutetabell svarer på hvor pakken videresendes. Kryptopolicyen svarer på hvilken beskyttelse og hvilken peer som gjelder for den valgte trafikken. Duplisering av et kilde- og destinasjonspar under en annen peer endrer den andre beslutningen og lar den første være urørt, så svar kan fortsatt følge den gamle gatewayen mens den utgående pakken tar den nye peeren. Den asymmetrien produserer en tunnel som rapporterer oppe og ikke slipper noe gjennom.
Hold også kontrakten gjensidig med den fjerne enden: akseptert identitet, beskyttede adresseområder, en returrute for de interessante prefiksene og tillatelse for tjenesten. Et alternativt utgående valg som den andre siden ikke forventer, er ikke en alternativ vei, det er halvparten av en.
Hva en ekte alternativ vei trenger
Velg en mekanisme som er laget for jobben: en støttet gruppe peer-kandidater, en rutet tunnel med en flytende statisk eller dynamisk rutingsnærhet over den, eller hvilket som helst redundansdesign plattformen din dokumenterer for den tjenesten. Skriv så ned hvilken komponent som oppdager feilen, og hvilken komponent som velger alternativet, for det er to forskjellige funksjoner og ofte to forskjellige team.
Adresseoversettelse kan også gi et nettsted en andre presentert adresse, men den endrer samtidig selektorer, logging og kildebaserte tilgangsregler. Behandle det som et eksplisitt krav i stedet for som en omvei for to tvetydige oppføringer.
Test tre tilstander, ikke én
Konfigurasjonen er først ferdig når den har et forsvarlig svar for normal drift, for tilstanden med feilet primær og for tilbakevending til primær. Test alle tre og noter hvilken policyoppføring og hvilken peer som betjente hver av dem. En test som stopper etter den første tilstanden, beviser at designet virker når ingenting er galt, og det er tilstanden du ikke trengte å sjekke.
Skille også mellom konfigurert overlapping og den legitime sameksistensen av gamle og nye assosiasjoner under en nøkkelfornyelse. Flere aktive SA-er er normale og midlertidige; to oppføringer som kjemper om én flyt, er permanente og usynlige.