GDOI: miért nincs a kulcsszerver az adatútvonalon

A csoportos kulcsszerver szabályzatot és kulcsokat oszt ki a tagoknak, a tagok pedig maguk védik a forgalmat. Ez a mondat formalitásnak hangzik, amíg egy tervezet nem kezeli a vezérlőt minden védett csomag továbbítójaként; akkor a topológia kap egy ugrást, amelyre soha nem volt szüksége, és a forgalom útvonala olyan eszköztől függ, amelynek csak állapotot kellett kiosztania. Mást jelent, hol ül a kulcsszerver, és mást, hova folynak az adatok: ez két külön diagram, és a GDOI pontosan erre a különbségre épül. Ezt visszájára fordítani nem kis modellezési hiba, mert megváltoztatja, mit figyel és mit méretez. Az alábbi szakaszok a protokoll saját felosztását követik.

Kétféle biztonsági állapot

RFC 6407 meghatározza a tag húzó cseréjét a szabályzat és kulcsanyag kérésére, valamint egy toló cserét, amely szabályzatot és kulcsfrissítéseket oszt ki a jogosult tagoknak. Mindkettő biztonsági társításokat kezel. Egyik sem az alkalmazás adatfolyama, ezért egy sikeres csere csak azt bizonyítja, hogy a vezérlőcsatorna működött. Egy tag tisztán regisztrálhat, érvényes kulcsokat tarthat, és mégsem tudja védeni vagy továbbítani a forgalmat, ha az adatszabályzata hibás. A két hiba teljesen másképp néz ki, ha tudja, melyik cserét melyik hordozza.

A szabvány említ egy kulcsfrissítési biztonsági társítást is, amely a kulcsfrissítési üzeneteket védi, elkülönítve azoktól az adatbiztonsági társításoktól, amelyek leírják, hogyan védik a tagok a forgalmat.

Kövesse a cseréket, ne a diagramot

Nézze meg, mire való minden üzenet. A regisztráció megmondja a vezérlőnek, melyik tag kérdez, és állapotot hoz létre; a kulcsfrissítés megmondja a tagoknak, hogy a szabályzat vagy a kulcsok megváltoztak; ezután a védett alkalmazásforgalom a telepített adatbiztonsági társítással folyik a tagok között. A vezérlő címe az első kettőben jelenik meg, a harmadikban egyáltalán nem kell megjelennie.

Ezért a fizikai szomszédosság szerint rajzolt interfész-diagram itt félrevezet. A vezérlő interfésze vezérlési forrás, nem automatikusan minden titkosított csomag következő ugrása.

Három nyilvántartás, amit érdemes megtartani

Írja fel a tag hitelesített regisztrációját és az elérhető vezérlési forrást, a későbbi kulcsfrissítéseket kézbesítő útvonalat, valamint a védett alkalmazásforgalmat hordozó útvonalakat és csatlakozásokat. Három nyilvántartás, három tulajdonos, és bármelyikük hibája más tünetet ad. Az a tag, amelyik regisztrál, majd soha nem kap frissítést, pontosan úgy néz ki, mint aki elavult szabályzattal regisztrált, hacsak nincs meg mindkét nyilvántartás.

Tartsa ezeket a konfiguráció mellett, ne valaki emlékezetében. A tagsági változások elég ritkák ahhoz, hogy az indoklás mindig eltűnik, mire szükség van rá.

Interfész, szolgáltatáscsatlakozás, feldolgozási útvonal

A szolgáltatásalapú átjárón van egy további megkülönböztetés: a fizikai alaphálózati cím nem ugyanaz, mint a helyi szolgáltatáscsatlakozás, és a platform megvalósítása dönti el, hogyan érkezik a forgalom az IPsec-feldolgozási útvonalára. Egy szolgáltatás fizikai interfészre mozgatása vagy nem kapcsolódó fordítás hozzáadása, mert egy hibaüzenet szolgáltatás-interfész szabályt említett, javításnak öltöztetett találgatás.

Olvassa el a platform saját dokumentációját arról, hogyan fogadja a forgalmat a szolgáltatáscsatlakozás. A mechanizmus szállítófüggő akkor is, ha a protokoll szabványos.

A szabványosított protokollüzenetek sem teremtenek szállítók közötti kompatibilitást. Hasonlítsa össze a szükséges funkciókat, a szabályzat- és társításattribútumokat, a hitelesítési módszert, valamint a pontos platformot és kiadást, mielőtt feltételezi, hogy két megvalósítás együttműködik.

A vezérlés elérhetősége és az adattovábbítás külön ellenőrzés

Tervezze meg a vezérlő elérhetőségét a rendes működéshez, a tagsági változásokhoz és a kulcsfrissítésekhez. Egy alkalmazáscsere, amely már telepített állapoton sikerül, nem bizonyítja, hogy a következő regisztráció vagy frissítés eléri a tagot, és a hiány általában órákkal később egy alagútként jelenik meg, amely már nem fogad új tagokat. Teszteljen friss regisztrációt, ne csak egy működő munkamenetet.

Utána tesztelje a továbbítást külön, a vezérlőt kihagyva. Két ellenőrzés, két eredmény, és sokkal rövidebb vita arról, melyik fél hibás.