GDOI: зашто сервер кључева није на вашој путањи података

Групни сервер кључева дели политику и кључеве члановима, а чланови сами штите саобраћај. Та реченица звучи као формалност све док неки дизајн не почне да третира контролер као релеј за сваки заштићени пакет; тада топологија добија скок који јој никада није био потребан, а путања саобраћаја зависи од уређаја који је само требало да издаје стање. Рећи где се налази сервер кључева и рећи куда теку подаци су две различите шеме, а GDOI је изграђен управо око те разлике. Обрнути то није мала грешка у моделовању, јер мења шта надгледате и шта скалирате. Одељци испод следе сопствену поделу протокола.

Две врсте безбедносног стања

RFC 6407 дефинише размену повлачења члана за тражење политике и кључног материјала и размену гурања која дели политику и ажурирања кључева овлашћеним члановима. Обе управљају безбедносним асоцијацијама. Ниједна није ток података апликације, па успешна размена доказује само да је контролни канал радио. Члан може чисто да се региструје, држи важеће кључеве и ипак не успе да заштити или проследи саобраћај ако је његова политика података погрешна. Те две грешке изгледају потпуно различито када знате која размена коју носи.

Стандард такође именује безбедносну асоцијацију обнове кључева која штити поруке ажурирања кључева, одвојено од безбедносних асоцијација података које описују како чланови штите саобраћај.

Пратите размене, не шему

Погледајте чему служи свака порука. Регистрација каже контролеру који члан пита и успоставља стање; обнова кључева каже члановима да су се политика или кључеви променили; затим заштићени саобраћај апликације тече између чланова користећи инсталирану безбедносну асоцијацију података. Адреса контролера се појављује у прве две и уопште не мора да се појави у трећој.

Зато шема интерфејса нацртана по физичкој суседности овде наводи на погрешан закључак. Интерфејс контролера је извор контроле, а не аутоматски следећи скок за сваки шифровани пакет.

Три записа које вреди чувати

Запишите аутентификовану регистрацију члана и контролни извор до којег може да стигне, путању која доставља каснија ажурирања кључева, као и руте и прикључке који носе заштићени саобраћај апликације. Три записа, три власника, а грешка у било ком од њих даје другачији симптом. Члан који се региструје и потом никада не добије ажурирање изгледа исто као члан регистрован са застарелом политиком, осим ако имате оба записа.

Чувајте ово поред конфигурације, а не у нечијем сећању. Промене чланства су довољно ретке да образложење увек нестане до тренутка када је потребно.

Интерфејс, прикључак услуге, путања обраде

На мрежном пролазу заснованом на услугама постоји још једна разлика: адреса физичког подлога није исто што и локални прикључак услуге, а имплементација платформе одлучује како саобраћај стиже до њене путање обраде IPsec. Премештање услуге на физички интерфејс или додавање неповезаног превода јер је порука о грешци поменула правило интерфејса услуге је претпоставка обучена у поправку.

Прочитајте сопствену документацију платформе о томе како прикључак услуге прима саобраћај. Механизам зависи од добављача чак и када је протокол стандардан.

Стандардизоване протоколске поруке такође не успостављају компатибилност између добављача. Упоредите обавезне функције, атрибуте политике и асоцијације, метод аутентификације и тачну платформу и издање пре него што претпоставите да ће две имплементације сарађивати.

Доступност контроле и прослеђивање података су одвојене провере

Планирајте доступност контролера за уобичајени рад, за промене чланства и за ажурирања кључева. Размена апликације која успе на већ инсталираном стању не доказује да следећа регистрација или обнова може да стигне до члана, а јаз се обично појави сатима касније као тунел који престаје да прима нове чланове. Тестирајте свежу регистрацију, не само радну сесију.

Затим тестирајте прослеђивање одвојено, без контролера. Две провере, два резултата и много краћа расправа о томе која је половина покварена.