Стоит ли наслаивать два уровня VPN? Три условия для проверки
Два уровня VPN помогают только тогда, когда они заканчиваются на разных хостах и используют независимые ключи. Три условия решают, добавляет ли вложенность безопасность или только нагрузку на процессор.
Прежде чем добавить второй уровень шифрования в VPN, честно ответьте на один вопрос: что остаётся у наблюдателя после того, как оба уровня сделали свою работу? Если ответ — внутренний шифротекст, неизменный, то вложенность купила время и ничего больше. Дальше следует процедура принятия решения, а не рекомендация. Одна и та же схема оказывается потраченным процессором в одном развёртывании и правильным ответом в другом, и разделяют их только три условия.
Запишите, что сохраняет наблюдатель
Зафиксируйте объект, который противник может сохранить сегодня, а затем последовательность снятий, которая в итоге раскрыла бы открытый текст. Внешний туннель создаёт шифротекст; когда его защита заканчивается, остаётся шифротекст внутреннего туннеля, всё ещё запечатанный. Снять обёртку — не расшифровать. Это предложение описывает вложенность, и оно верно лишь пока жив внутренний ключ. В тот момент, когда два уровня хоть что-то разделяют, шкала времени сжимается в одно событие.
Итак, полезный артефакт — шкала времени, а не схема из прямоугольников. Для каждого уровня запишите конечную точку, владельца ключа, проверку личности и год, в котором ожидается отказ допущения.
Практический способ проверить собственное утверждение: предположите, что наблюдатель записывает всё и никогда не сдаётся. При таком допущении защищает ли проект полезную нагрузку в течение требуемого срока? Если ответ зависит от того, что наблюдатель решит не хранить трафик, у проекта нет ответа.
Условие первое: заканчиваются ли уровни в разных местах?
Вложенность окупается, когда два уровня заканчиваются в разных доменах доверия, например шлюз IPsec под управлением провайдера перед туннелем прикладного уровня, который заканчивается внутри вашей собственной сети. Тогда взлом внешнего уровня даёт шифротекст, открыть который может только ваш хост, а провайдер ни в какой момент не видит открытого текста. Поместите оба уровня на один и тот же шлюз — и это свойство исчезает. Кто скомпрометирует коробку, тот читает трафик между двумя операциями расшифрования, сколько бы обёрток ни показывала схема.
Проверяйте это установленным состоянием, а не проектом. В Linux ip xfrm state перечисляет каждую ассоциацию безопасности и её конечные точки, что и определяет, где на самом деле останавливается каждый уровень.
Условие второе: действительно ли независим ключевой материал?
Два уровня, построенные из одного сертификата, одного предварительно разделённого ключа или одной библиотеки поставщика, — это один уровень с лишними шагами. Тогда одна утёкшая учётная запись открывает оба, а одна ошибка реализации убирает оба сразу. Независимость должна быть видна в конфигурации, а не заявлена на слайде.
Именно здесь гибридное установление ключей превосходит наслаивание туннелей. IKEv2 может провести несколько обменов ключами в одних переговорах, поэтому классическая группа и постквантовый KEM могут оба питать одни и те же сеансовые ключи вместо того, чтобы оборачиваться друг вокруг друга. Результат — одна ассоциация безопасности, ключи которой зависят от обоих секретов, и атакующему приходится ломать оба. Это документированная конструкция с определённым составом, чего нельзя сказать о самодельном стеке из двух продуктов VPN. В strongSwan swanctl --list-sas печатает согласованное предложение для каждой SA, и так вы подтверждаете, что действительно работало, а не что вы настроили.
Условие третье: переживают ли данные внешнее допущение?
Уровню, который должен держаться двадцать лет, нужен двадцатилетний аргумент. Записать сейчас и расшифровать позже дёшево, и именно поэтому классический внешний уровень нельзя рассматривать как временную обёртку вокруг чего-то более стойкого.
Спрашивайте, когда каждый ключ становится восстановимым, а не сломан ли шифр сегодня. Статический обмен ключами без прямой секретности отказывает задним числом в тот день, когда падает закрытый ключ. Эфемерное согласование ключей отказывает только для сеансов, которые атакующий может атаковать, пока они живы, или когда слабеет сам алгоритм. Эта разница решает, помогает ли внутренний уровень ещё в 2040 году. Она же решает, меняет ли внешний уровень вообще что-нибудь, ведь внешний уровень с более слабым сроком жизни ключа просто становится самой ранней точкой на шкале времени.
Что строить вместо этого, когда ответ отрицательный
Если любое из трёх условий не выполняется, откажитесь от вложенности и потратьте усилие на уровень, который действительно несёт требование к сроку. Настройте гибридный обмен ключами в протоколе, который вы уже используете, поддерживайте реализацию актуальной и запишите состав, на который вы полагаетесь. Упоминание ML-KEM в проектном документе не является свойством безопасности, а FIPS 203 определяет механизм инкапсуляции ключей, а не ваш туннель.
Там, где второй уровень действительно заслуживает своё место, описывайте его как защиту в глубину, а не как доказательство. Затем проверьте состав: какая конечная точка держит какой ключ, какую личность проверяет каждая сторона и что может прочитать оператор с доступом к консоли. Проект, который проходит эти три вопроса, стоит дополнительного процессора. Тот, который не проходит, — всего лишь схема.
Перед окном изменений зафиксируйте текущую таблицу SA и согласованные предложения, а после него зафиксируйте их снова и сравните, потому что единственное доказательство, которое имеет значение, — это то, о чём устройства действительно договорились.