GDOI: proč klíčový server není na cestě vašich dat

Skupinový klíčový server rozděluje politiku a klíče členům a členové sami chrání provoz. Ta věta zní jako formalita, dokud nějaký návrh nezačne považovat kontroler za přeposílací uzel pro každý chráněný paket; pak topologie získá skok, který nikdy nepotřebovala, a cesta provozu závisí na zařízení, které mělo jen vydávat stav. Říct, kde klíčový server sedí, a říct, kudy tečou data, jsou dva různé diagramy a GDOI je postaven právě na tomto rozdílu. Otočit to není malá chyba modelování, protože mění, co sledujete a co škálujete. Následující oddíly drží vlastní dělení protokolu.

Dva druhy bezpečnostního stavu

RFC 6407 definuje členskou výměnu tažení pro žádost o politiku a klíčový materiál a výměnu tlačení, která rozděluje politiku a aktualizace klíčů oprávněným členům. Obě spravují bezpečnostní asociace. Ani jedna není datový tok aplikace, takže úspěšná výměna dokazuje jen to, že kontrolní kanál fungoval. Člen se může čistě zaregistrovat, držet platné klíče a přesto nedokázat chránit nebo předávat provoz, pokud je jeho datová politika špatná. Tyto dvě poruchy vypadají úplně jinak, jakmile víte, která výměna kterou nese.

Standard také pojmenovává bezpečnostní asociaci obnovy klíčů, která chrání zprávy o aktualizaci klíčů, odděleně od datových bezpečnostních asociací, jež popisují, jak členové chrání provoz.

Sledujte výměny, ne diagram

Podívejte se, k čemu je každá zpráva. Registrace říká kontroleru, který člen se ptá, a vytváří stav; obnova klíčů říká členům, že se politika nebo klíče změnily; pak chráněný provoz aplikace teče mezi členy pomocí nainstalované datové bezpečnostní asociace. Adresa kontroleru se objevuje v prvních dvou a ve třetí vůbec nemusí.

Proto diagram rozhraní nakreslený podle fyzické sousednosti zde klame. Rozhraní kontroleru je zdroj řízení, ne automaticky další skok pro každý šifrovaný paket.

Tři záznamy, které stojí za to uchovat

Zapište členovu ověřenou registraci a řídicí zdroj, ke kterému se dostane, cestu, která doručuje následné aktualizace klíčů, a trasy a připojení, jež nesou chráněný provoz aplikace. Tři záznamy, tři vlastníci a porucha v kterémkoli z nich dává jiný symptom. Člen, který se zaregistruje a pak nikdy nedostane aktualizaci, vypadá stejně jako člen registrovaný se zastaralou politikou, pokud nemáte oba záznamy.

Uchovejte to vedle konfigurace, ne v něčí paměti. Změny členství jsou dost vzácné na to, aby odůvodnění vždy zmizelo do chvíle, kdy je potřeba.

Rozhraní, připojení služby, cesta zpracování

Na bráně založené na službách existuje další rozdíl: adresa fyzického podkladu není totéž co místní připojení služby a implementace platformy rozhoduje, jak se provoz dostane na její cestu zpracování IPsec. Přesunout službu na fyzické rozhraní nebo přidat nesouvisející překlad, protože chybová zpráva zmínila pravidlo rozhraní služby, je dohad oblečený jako oprava.

Přečtěte si vlastní dokumentaci platformy o tom, jak připojení služby přijímá provoz. Mechanismus je specifický pro dodavatele, i když je protokol standardní.

Standardizované protokolové zprávy také nezakládají kompatibilitu mezi dodavateli. Porovnejte požadované funkce, atributy politiky a asociace, metodu ověřování a přesnou platformu a vydání, než předpokládáte, že dvě implementace budou spolupracovat.

Dostupnost řízení a předávání dat jsou samostatné kontroly

Plánujte dosažitelnost kontroleru pro běžný provoz, pro změny členství a pro aktualizace klíčů. Výměna aplikace, která uspěje na již nainstalovaném stavu, nedokazuje, že další registrace nebo obnova dokáže člena dosáhnout, a mezera se obvykle objeví o hodiny později jako tunel, který přestane přijímat nové členy. Otestujte čerstvou registraci, ne jen fungující relaci.

Potom otestujte předávání zvlášť, bez kontroleru. Dvě kontroly, dva výsledky a mnohem kratší spor o to, která polovina je rozbitá.