Hold to rutebøker i et IPsec-lab: underlag og beskyttet

To spørsmål floker seg sammen i et IPsec-lab: hvordan en pakke når motpartens ytre adresse, og hvordan den når de private nettene bak den motparten. De hører i atskilte bøker, fordi ulike ruteprosesser svarer på dem, og de feiler med ulike symptomer. Hold underlagsboken for eksterne endepunkter og neste hopp som når dem. Hold overlegsboken for beskyttede prefikser, gatewayene deres og den tiltenkte veien gjennom tunnelen. Mesteparten av forvirringen i laben kommer av at en rute som med rette finnes i én bok, leses som bevis om den andre.

To bøker, to spørsmål

Bøkene holder seg korte nok til å føres for hånd mens laben er liten, og det er nettopp da de er mest nyttige. To kolonner er nok: hva oppføringen er, og hvordan den nås.

Skriv begge retninger. Et prefiks som finnes i den utgående boken og ikke i returboken, gir en tunnel som bærer forespørsler og slipper svar. Den halvfungerende tilstanden er det vanligste resultatet i laben, og den forveksles lett med et policyproblem.

Skriv destinasjonen før protokollen

Start med destinasjonene, ikke protokollene. For hver gateway, noter den ytre adressen og neste hopp som når den. Noter deretter hvert private prefiks, gatewayen på stedet og veien det skal ta gjennom tunnelen.

Å gjøre det før man velger en ruteprotokoll holder diskusjonen ærlig. Designet kommer med krav i stedet for preferanser. Diskusjonen om hvilken protokoll som skal kjøres blir da et spørsmål om hvilket krav som faktisk er vanskelig.

Statisk eller dynamisk, avgjort per bok

Statisk ruting på transportsiden er vanligvis riktig i en lab: to endepunkter, ett neste hopp, ingenting å konvergere. Den private siden kan med rimelighet være dynamisk, fordi prefikser kommer og går med øvelsen. Å kjøre én ruteprotokoll på transportsiden og en annen på den private siden forplikter deg ikke til å omfordele mellom dem, og å behandle gjensidig omfordeling som en forutsetning for IPsec er der laber begynner å produsere resultater ingen kan forklare.

Bestem de to bøkene hver for seg, og noter hvilken som er dynamisk. Ett svar for begge sider betyr vanligvis at de to spørsmålene aldri ble ordentlig skilt.

Omfordeling er en policygrense

Der ruter må krysse, gjør kryssingen til en policy med navngitte prefikser, retning, metrikkbehandling og løkkevakt. Prefikslister og rutekart gir deg alle fire, og tagger holder en omfordelt rute identifiserbar etter at den har mistet den opprinnelige konteksten. Les semantikken nøye, fordi de ikke er utbyttbare: et ACL-avslag inne i en match-klausul betyr at ruten ikke matcher og vurderingen fortsetter, mens en avslagssekvens i et rutekart stopper ruten fra å bli omfordelt i det hele tatt. Veiledningen for rutekart ved omfordeling dekker disse klausulene og attributtendringene som følger med.

Sammenlign deretter den resulterende rutetabellen med begge bøkene. En lab som begynner å videresende etter bred omfordeling, har vist rekkevidde, ikke intensjon. Enhver tabelloppføring som ikke finnes i noen av bøkene, betyr at eksporten er bredere enn designet, og hver senere annonsering arver denne tvetydigheten.

Hold sikkerhetseksemplet like oppdatert som rutingen

Gamle gjennomganger som bygger på svake algoritmer eller en delt demonstrasjonshemmelighet, er historiske observasjoner. Å kopiere dem inn i en lab du vil utvide, er hvordan svake standardverdier overlever i produksjon. Bruk policyen plattformen støtter, og noter versjonen du testet, fordi laben lever lenger enn opplæringen.

Godta én godkjent vert-til-vert-strøm, returtrafikken og én destinasjon som må holde seg utenfor beskyttelsesområdet. Lagre ruteopphavet og de forhandlede selektorene sammen med hvert resultat, slik at protokollen viser hvilket lag som ble bevist, ikke hvilket lag som tilfeldigvis var oppe.

Når noe brytes, forteller boken hvilket lag du skal åpne. Ingen nåbarhet til motparten er transport, ingen indre rute er privat vei, og en rute som finnes uten samsvarende selektor, er policy. Tre setninger, én diagnose, ingen gjetting.