GDOI: kvifor nøkkelserveren ikkje ligg på datastien din

Nøkkelserveren til gruppa fordeler policy og nøklar til medlemmane, og medlemmane vernar trafikken sjølve. Den setninga høyrest ut som ein formalitet heilt til eit design behandlar kontrollaren som eit relé for kvar verna pakke; då får topologien eit hopp han aldri trong, og trafikkvegen avheng av ei eining som berre skulle dela ut tilstand. Å seia kvar nøkkelserveren står, og å seia kvar dataa flyt, er to ulike diagram, og GDOI er bygt rundt nettopp denne skilnaden. Å snu det er ikkje ein liten modelleringsfeil, fordi det endrar kva du overvakar og kva du skalerer. Avsnitta nedanfor følgjer den eigne inndelinga til protokollen.

To slag tryggleikstilstand

RFC 6407 definerer trekkeutvekslinga til medlemmet for å be om policy og nøkkelmateriale, og ei skyveutveksling som fordeler policy og nøkkeloppdateringar til autoriserte medlem. Begge styrer tryggleiksassosiasjonar. Ingen av dei er datastraumen til applikasjonen, så ei vellukka utveksling beviser berre at kontrollkanalen verka. Eit medlem kan registrera seg reint, halda gyldige nøklar og likevel ikkje verna eller videresenda trafikk dersom datapolicyen er feil. Dei to feila ser heilt ulike ut når du veit kva utveksling som ber kva.

Standarden namngir òg ein tryggleiksassosiasjon for nøkkeloppdatering som vernar nøkkeloppdateringsmeldingar, skild frå tryggleiksassosiasjonane for data som skildrar korleis medlemmane vernar trafikk.

Følg utvekslingane, ikkje diagrammet

Sjå kva kvar melding er til. Registreringa fortel kontrollaren kva medlem som spør og set opp tilstand; nøkkeloppdateringa fortel medlemmane at policy eller nøklar er endra; deretter flyt verna applikasjonstrafikk mellom medlemmane via den installerte tryggleiksassosiasjonen for data. Adressa til kontrollaren viser seg i dei to første og treng ikkje visa seg i det heile i den tredje.

Difor eit grensesnittdiagram teikna etter fysisk naboskap villedar her. Grensesnittet til kontrollaren er ei kontrollkjelde, ikkje automatisk neste hopp for kvar kryptert pakke.

Tre oppføringar det er verdt å ta vare på

Skriv ned den autentiserte registreringa til medlemmet og kontrollkjelda det kan nå, vegen som leverer seinare nøkkeloppdateringar, og rutene og tilkoblingane som ber verna applikasjonstrafikk. Tre oppføringar, tre eigarar, og ein feil i kvar av dei gjev eit anna symptom. Eit medlem som registrerer seg og deretter aldri mottek ei oppdatering, ser identisk ut med eit medlem som registrerte seg med utdatert policy, med mindre du har begge oppføringane.

Oppbevar desse ved sida av konfigurasjonen i staden for i minnet til nokon. Endringar i medlemskap er sjeldne nok til at grunngjevinga alltid er borte når ho trengst.

Grensesnitt, tenestetilkopling, handsamingsveg

På ein tenestebasert gateway er det ein ytterlegare skilnad: den fysiske underlagsadressa er ikkje det same som den lokale tenestetilkoplinga, og implementasjonen til plattforma avgjer korleis trafikk når IPsec-handsamingsvegen hennar. Å flytta ein teneste til eit fysisk grensesnitt eller leggja til urelatert omsetjing fordi ei feilmelding nemnde ein tenestegrensesnittregel, er ei gjetting kledd som ei retting.

Les den eigen dokumentasjonen til plattforma om korleis tenestetilkoplinga mottek trafikk. Mekanismen er leverandørspesifikk sjølv når protokollen er standard.

Standardiserte protokollmeldingar etablerer heller ikkje kompatibilitet mellom leverandørar. Samanlikn naudsynte funksjonar, policy- og assosiasjonsattributtar, autentiseringsmetode og den nøyaktige plattforma og versjonen før du går ut frå at to implementasjonar vil samhandla.

Kontrolltilgjenge og datavideresending er separate kontrollar

Planlegg tilgjenge til kontrollaren for vanleg drift, for endringar i medlemskap og for nøkkeloppdateringar. Ei applikasjonsutveksling som lykkast på allereie installert tilstand, beviser ikkje at den neste registreringa eller oppdateringa kan nå medlemmet, og gapet viser seg vanlegvis timar seinare som ein tunnel som sluttar å ta imot nye medlem. Test ei fersk registrering, ikkje berre ein fungerande sesjon.

Test deretter videresending separat, med kontrollaren ute av biletet. To kontrollar, to resultat og ein mykje kortare diskusjon om kva halvdel som er øydelagd.