Статический ключ или TLS для соединения OpenVPN между двумя узлами?

Две машины, которые общаются только друг с другом, могут сохранить эту топологию и всё же получить согласованные ключи трафика. Форма сети и режим защиты — независимые решения, и именно их смешение заставляет людей пытаться обновить статический секрет заменой файла, пока оба демона продолжают работать. Замена файла ключа у работающей пары не обновляет ничего. Статический режим, который OpenVPN 2.6 помечает как устаревший, держит один ключ на всё время жизни туннеля, поэтому файл на диске и ключ в памяти снова совпадают только после перезапуска обоих концов. Если требуется автоматическое обновление, режим защиты должен измениться.

Чего не может статический режим

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

В руководстве OpenVPN 2.6 прямо сказано, что ключ сохраняется, пока не будет создан новый. Это приемлемо для лабораторного соединения или фиксированной пары устройств с документированной процедурой обновления, и неприемлемо там, где долгоживущий секрет является реальным риском. Замена файла не создаёт новый ключ для работающей пары; она создаёт два узла, которые расходятся. Поэтому замена файла добавляет простой, не добавляя обновления ключей.

Также нет понятия личности узла, кроме владения файлом. Любой, у кого есть ключ, является узлом, и ничто в туннеле не фиксирует, какая сторона какая, поэтому отзыв — это всё или ничего.

Переход на TLS без переработки соединения

Режим TLS добавляет канал управления и вместе с ним возможность согласовывать ключи канала данных. При развёртывании «точка — точка» одна сторона берёт роль сервера, а другая — клиента, но топология остаётся соединением двух узлов: каждая сторона знает конечную точку другой, и никакой пул или многопользовательская служба не появляется. Роли — деталь рукопожатия, а не новая архитектура.

Дайте каждой машине собственную личность. Каждой стороне нужны сертификат и закрытый ключ, якорь доверия, проверяющий другую сторону, и правило проверки узла, называющее, кого ожидают. Не используйте закрытый ключ одного узла на другом ради экономии времени; это превращает две личности в одну и лишает возможности отозвать любую сторону отдельно. Регистрация — место, где это делается правильно, потому что исправление позже означает перевыпуск сертификатов.

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

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

Кто что обновляет и когда

В режиме TLS обновление определяется настроенными пределами: интервалом времени, числом байтов или числом пакетов. Документированное управление по времени — то, на что полагается большинство развёртываний, и меньшее действующее значение на двух узлах может запустить замену, поэтому повышение только с одной стороны не удержит событие. Пределы по объёму существуют потому, что загруженное соединение может исчерпать ключ задолго до того, как это сделают часы. Ни один предел не является проверкой состояния, и ни один не сообщает, что обновление прошло успешно.

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

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

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

Принятие изменения

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

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

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