GDOI: почему сервер ключей не находится на пути данных

Групповой сервер ключей распространяет политику и ключи среди участников, а участники сами защищают трафик. Эта фраза звучит как формальность, пока какая-нибудь схема не начнёт считать контроллер ретранслятором каждого защищённого пакета; тогда топология получает лишний переход, а путь трафика начинает зависеть от устройства, которое должно было лишь выдавать состояние. Сказать, где стоит сервер ключей, и сказать, куда идут данные, — это две разные схемы, и GDOI построен именно вокруг этой разницы. Обратное понимание — не мелкая ошибка моделирования, потому что оно меняет то, за чем вы наблюдаете и что масштабируете. Разделы ниже следуют собственному делению протокола.

Два вида состояния безопасности

RFC 6407 определяет обмен выборки участника для запроса политики и ключевого материала, а также обмен проталкивания, который распространяет политику и обновления ключей авторизованным участникам. Оба управляют ассоциациями безопасности. Ни один из них не является потоком данных приложения, поэтому успешный обмен доказывает только то, что канал управления работал. Участник может чисто зарегистрироваться, держать действительные ключи и всё равно не суметь защитить или переслать трафик, если его политика данных неверна. Эти две неисправности выглядят совершенно по-разному, когда знаешь, какой обмен какую несёт.

Стандарт также называет ассоциацию безопасности обновления ключей, которая защищает сообщения об обновлении ключей, отдельно от ассоциаций безопасности данных, описывающих, как участники защищают трафик.

Следите за обменами, а не за схемой

Посмотрите, для чего каждое сообщение. Регистрация сообщает контроллеру, какой участник спрашивает, и создаёт состояние; обновление ключей сообщает участникам, что политика или ключи изменились; затем защищённый трафик приложения идёт между участниками через установленную ассоциацию безопасности данных. Адрес контроллера появляется в первых двух и совсем не обязан появляться в третьем.

Поэтому схема интерфейсов, нарисованная по физическому соседству, здесь вводит в заблуждение. Интерфейс контроллера — это источник управления, а не автоматически следующий переход для каждого зашифрованного пакета.

Три записи, которые стоит хранить

Запишите аутентифицированную регистрацию участника и источник управления, до которого он может добраться, путь, доставляющий последующие обновления ключей, а также маршруты и подключения, несущие защищённый трафик приложения. Три записи, три владельца, и сбой в любой из них даёт другой симптом. Участник, который регистрируется и затем никогда не получает обновление, выглядит так же, как участник, зарегистрированный с устаревшей политикой, если у вас нет обеих записей.

Храните это рядом с конфигурацией, а не в чьей-то памяти. Изменения членства настолько редки, что обоснование всегда исчезает к моменту, когда оно нужно.

Интерфейс, подключение службы, путь обработки

На шлюзе на основе служб есть ещё одно различие: адрес физической основы — не то же самое, что локальное подключение службы, и реализация платформы решает, как трафик попадает на её путь обработки IPsec. Перенос службы на физический интерфейс или добавление несвязанного преобразования из-за того, что сообщение об ошибке упомянуло правило интерфейса службы, — это догадка в костюме исправления.

Прочитайте собственную документацию платформы о том, как подключение службы принимает трафик. Механизм зависит от поставщика, даже когда протокол стандартный.

Стандартизованные сообщения протокола также не устанавливают совместимость между поставщиками. Сравните требуемые функции, атрибуты политики и ассоциации, метод аутентификации, а также точную платформу и выпуск, прежде чем предполагать, что две реализации будут взаимодействовать.

Доступность управления и пересылка данных — отдельные проверки

Планируйте доступность контроллера для обычной работы, для изменений членства и для обновлений ключей. Обмен приложения, успешный на уже установленном состоянии, не доказывает, что следующая регистрация или обновление сможет достичь участника, и разрыв обычно проявляется через часы как туннель, который перестаёт принимать новых участников. Проверяйте новую регистрацию, а не только работающий сеанс.

Затем проверьте пересылку отдельно, без контроллера. Две проверки, два результата и гораздо более короткий спор о том, какая половина сломана.