Håll två ruttloggar i ett IPsec-lab: underlag och skyddat

Två frågor trasslar ihop sig i ett IPsec-lab: hur ett paket når motpartens yttre adress, och hur det når de privata näten bakom den motparten. De hör hemma i separata loggar, eftersom olika routingprocesser svarar på dem och de misslyckas med olika symptom. Håll underlagsloggen för externa ändpunkter och nästa hopp som når dem. Håll överliggande loggen för skyddade prefix, deras gateways och den avsedda vägen genom tunneln. Det mesta av förvirringen i labbet kommer av att en rutt som med rätta finns i den ena loggen läses som bevis om den andra.

Två loggar, två frågor

Loggarna hålls korta nog att föras för hand medan labbet är litet, och det är just då de är mest användbara. Två kolumner räcker: vad posten är, och hur den nås.

Skriv båda riktningarna. Ett prefix som finns i den utgående loggen och inte i returloggen ger en tunnel som bär förfrågningar och tappar svar. Det halvfungerande tillståndet är det vanligaste resultatet i labbet, och det förväxlas lätt med ett policyproblem.

Skriv destinationen före protokollet

Börja med destinationerna, inte protokollen. För varje gateway, notera den yttre adressen och nästa hopp som når den. Notera sedan varje privat prefix, dess lokala gateway och den väg det bör ta genom tunneln.

Att göra det innan en routingprotokoll väljs håller diskussionen ärlig. Designen kommer med krav i stället för preferenser. Diskussionen om vilket protokoll som ska köras blir då en fråga om vilket krav som faktiskt är svårt.

Statiskt eller dynamiskt, avgjort per logg

Statisk routing på transportsidan är oftast rätt i ett labb: två ändpunkter, ett nästa hopp, inget att konvergera. Den privata sidan kan skäligen vara dynamisk, eftersom prefix kommer och går med övningen. Att köra ett routingprotokoll på transportsidan och ett annat på den privata sidan tvingar dig inte att omfördela mellan dem, och att behandla ömsesidig omfördelning som en förutsättning för IPsec är där labb börjar producera resultat som ingen kan förklara.

Bestäm de två loggarna var för sig och notera vilken som är dynamisk. Ett svar för båda sidorna betyder oftast att de två frågorna aldrig verkligen separerades.

Omfördelning är en policygräns

Där rutter måste korsa varandra, gör korsningen till en policy med namngivna prefix, riktning, metrikhantering och en slingvakt. Prefixlistor och ruttkartor ger dig alla fyra, och taggar håller en omfördela rutt identifierbar efter att den har tappat sitt ursprungliga sammanhang. Läs semantiken noga, eftersom de inte är utbytbara: ett ACL-avslag inne i en matchningsklausul betyder att rutten inte matchar och utvärderingen fortsätter, medan en avslagssekvens i en ruttkarta stoppar rutten från att omfördelas helt. Guiden för ruttkartor vid omfördelning täcker dessa klausuler och de attributändringar som följer med dem.

Jämför sedan den resulterande routingtabellen med båda loggarna. Ett labb som börjar vidarebefordra efter bred omfördelning har visat nåbarhet, inte avsikt. Varje tabellpost som inte finns i någon av loggarna betyder att exporten är bredare än designen, och varje senare annonsering ärver den tvetydigheten.

Håll säkerhetsexemplet lika aktuellt som routingen

Gamla genomgångar som bygger på svaga algoritmer eller en delad demonstrationshemlighet är historiska observationer. Att kopiera dem in i ett labb du tänker utöka är hur svaga standardvärden överlever i produktion. Använd policyn plattformen stöder och notera versionen du testade, eftersom labbet lever längre än handledningen.

Acceptera ett godkänt värd-till-värd-flöde, dess returtrafik och en destination som måste stanna utanför skyddsomfånget. Spara ruttens ursprung och de förhandlade selektorerna med varje resultat, så att protokollet visar vilket lager som bevisades, inte vilket lager som råkade vara uppe.

När något går sönder säger loggen vilket lager du ska öppna. Ingen nåbarhet till motparten är transport, ingen inre rutt är privat väg, och en rutt som finns utan matchande selektor är policy. Tre meningar, en diagnos, ingen gissning.