To kryptokart, éin flyt: den seinare oppføringa er ikkje ein sikkerheitskopi

Legg til ei andre kryptokart-oppføring for same adressepar, peik ho mot ein annan peer, og du har skrive ein failover-plan. Det er myten, og han overlever fordi han ser ut som kvar einaste annan ordna liste du har konfigurert. Rekkjefølgja i eit kryptokart avgjer kva oppføring som gjer krav på ein ny flyt, ikkje kva oppføring som tek over når ein peer sluttar å svare. Ingenting i den lista overvakar den fjerne enden, så den andre oppføringa sit berre der utan å gjere krav på noko som helst.

Myten: rekkjefølgje betyr reserve

Ei ordna liste med to oppføringar og éin delt definisjon kjennest som primær og sekundær. Likskapen sluttar ved syntaksen. ASAs dokumentasjon frå Cisco skildrar kryptokartet som policymodellen som matchar verna trafikk og namngjev peer-oppsettet for han, og matchinga skjer mot oppføringa som gjer krav på flyten først. Tilgjenge til ein ekstern peer er ikkje ein del av den vurderinga.

Det du har bygd, er ein policy som aldri vil bli konsultert for den flyten, pluss ein kommentar i ein endringslogg som hevdar redundans.

Rekkjefølgja gjer krav på flyten, og berre éin gong

Kvar oppføring held ei tilgangskontrolliste eller ein definisjon av ein verna flyt, og kvar ny utgåande pakke blir samanlikna med desse definisjonane i rekkjefølgje. Den første oppføringa der definisjonen stemmer, eig flyten og peeren sin. Ei andre oppføring med identisk definisjon får aldri ein tur, fordi den første allereie stemde; ei andre oppføring med ein snevrare definisjon tener berre flytar den første ikkje gjorde krav på.

Den åtferda er nyttig når du med vilje skjer unntak ut av ein brei policy, og ho er ubrukeleg som failover-mekanisme. Sjekk kva som faktisk skjedde med show crypto map og show crypto ipsec sa peer, og spor deretter ein syntetisk pakke gjennom vegen du trur han tek. Sporet vil namngje oppføringa som gjorde krav på han, og det er det einaste svaret som betyr noko.

Ruteval og policy-eigarskap er separate avgjerder

Ei rutetabell svarer på kvar pakken blir vidaresend. Kryptopolicyen svarer på kva vern og kva peer som gjeld for den valde trafikken. Duplisering av eit kjelde- og målpar under ein annan peer endrar den andre avgjerda og lèt den første vere urørt, så svar kan framleis følgje den gamle gatewayen medan den utgåande pakken tek den nye peeren. Den asymmetrien produserer ein tunnel som rapporterer oppe og ikkje slepp noko gjennom.

Hald òg kontrakten gjensidig med den fjerne enden: akseptert identitet, verna adresseområde, ein returveg for dei interessante prefiksa og løyve for tenesta. Eit alternativt utgåande val som den andre sida ikkje ventar, er ikkje ein alternativ veg, det er halvparten av ein.

Kva ein ekte alternativ veg treng

Vel ein mekanisme som er laga for jobben: ei støtta gruppe peer-kandidatar, ein ruta tunnel med ein flytande statisk eller dynamisk rutingsnærleik over han, eller kva som helst redundansdesign plattforma di dokumenterer for den tenesta. Skriv så ned kva komponent som oppdagar feilen, og kva komponent som vel alternativet, for det er to ulike funksjonar og ofte to ulike team.

Adresseomsetjing kan òg gje eit nettstad eit andre presentert adresse, men ho endrar samstundes selektorar, logging og kjeldebaserte tilgangsreglar. Handter det som eit eksplisitt krav i staden for som ein omveg for to tvitydige oppføringar.

Test tre tilstandar, ikkje éin

Konfigurasjonen er først ferdig når han har eit forsvarleg svar for normal drift, for tilstanden med feila primær og for tilbakevending til primær. Test alle tre og noter kva policyoppføring og kva peer som tente kvar av dei. Ein test som stoppar etter den første tilstanden, provar at designet verkar når ingenting er gale, og det er tilstanden du ikkje trong å sjekke.

Skil òg mellom konfigurert overlapping og den legitime sameksistensen av gamle og nye assosiasjonar under ein nøkkelfornying. Fleire aktive SA-ar er normale og mellombelse; to oppføringar som kjempar om éin flyt, er permanente og usynlege.