tls-auth против tls-crypt: что защищает каждый в OpenVPN

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

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

Что на самом деле защищает общий ключ

Ключ, который используют эти параметры, относится к каналу управления: обмену, который согласует параметры, доказывает идентичности и выводит ключи данных. Это заранее разделяемый секрет, который должен быть у обеих сторон до того, как рукопожатие продолжится. Поскольку он стоит перед проверками идентичности, неверный ключ останавливает разговор раньше, чем это сделал бы неверный пароль. Именно этот порядок объясняет, почему отказ выглядит так тихо.

tls-auth использует этот секрет, чтобы вычислить HMAC по управляющим пакетам. Пакет без действительной подписи отбрасывается до того, как дойдёт до более дорогой обработки TLS, поэтому этот параметр часто описывают как первый фильтр, а не как замену TLS.

tls-crypt идёт дальше: он не только удостоверяет защищённый управляющий трафик, но и шифрует его. Содержимое сертификатов, согласованные имена шифров и другие детали рукопожатия больше не видны в сети, и наблюдатель без ключа не может увидеть даже, какая версия TLS используется. Для развёртывания, которое боится раскрыть свой отпечаток VPN, это свойство и есть главная причина выбрать его. Но это по-прежнему групповой секрет, а не учётные данные отдельного пользователя.

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

Чем различаются два варианта

Наблюдаемое различие в том, что видит наблюдатель. С tls-auth рукопожатие видно, но без ключа его нельзя проверить. С tls-crypt рукопожатие непрозрачно для всех, у кого нет ключа.

Конфигурация тоже различается. tls-auth используется со значением направления, поэтому одна сторона берёт одну половину ключевого материала, а другая другую. tls-crypt использует один ключ в обоих направлениях, поэтому директива направления не входит в его схему.

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

Более новый вариант, tls-crypt-v2, привязывает каждого клиента к его собственному обёрнутому ключу, так что отзыв одного клиента не требует перевыпуска группового ключа. Об этом стоит знать, но это другой параметр и не синоним ни одного из двух здесь.

Почему несовпадение выглядит так, будто ничего не происходит

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

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

В журнале сервера читайте первую жалобу на уровне пакетов, а не последнюю строку повторной попытки. Убедитесь, что у обеих сторон один и тот же параметр с одинаковым ключевым материалом и что файл ключа не был создан заново только на одной стороне.

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

Что ещё нужно настраивать отдельно

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

Они также не выбирают шифр данных. Это отдельное согласование, которым управляют настройки канала данных на обеих сторонах, и туннель, защищённый с помощью tls-crypt, всё равно может использовать шифр, который вы не планировали.

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