Сравните два профиля OpenVPN, не раскрывая ключи

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

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

Что на самом деле несёт файл .ovpn

Файл .ovpn — это конфигурация с необязательными встроенными блоками. Он может содержать сертификат CA, клиентский сертификат, закрытый ключ, ключ tls-auth или tls-crypt, а также директивы, указывающие на внешние файлы или запрашивающие учётные данные. Два файла могут выглядеть почти одинаково и различаться только внутри блока или одной директивой, полностью меняющей транспорт. Число строк ничего не говорит о том, что из этого произошло.

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

Сравнивайте по роли, а не по строке

Идите в собственном порядке соединения: сначала конечная точка и транспорт, затем доверие и ожидаемая идентичность, затем аутентификация пользователя, затем маршруты, DNS и скриптовые хуки. Эта последовательность совпадает с тем, что делает клиент, поэтому первое различие, которое вы встретите, — это первое, что могло сломать соединение. Сравнение по алфавиту, наоборот, разбрасывает связанные настройки по всему выводу.

Проход с учётом полей смотрит на эти элементы в таком порядке. Всё, что клиент запрашивает интерактивно, относится к строке аутентификации, а не к строкам доверия.

  • remote, proto и порт, включая каждый блок соединения.
  • ca и cert: издатель, субъект и дата истечения.
  • Есть ли вообще закрытый ключ, а не что он содержит.
  • tls-auth или tls-crypt наличие и направление ключа.
  • Директивы аутентификации, включая любую ссылку на файл учётных данных.
  • Маршруты, параметры DNS и скриптовые хуки, запускаемые при подключении.

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

Почему обычный diff — неподходящий инструмент

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

openssl x509 -in ca.crt -noout -subject -issuer -enddate
openssl x509 -in client.crt -noout -subject -issuer -enddate
grep -E '^(remote|proto|port|tls-auth|tls-crypt|route|dhcp-option)' profile.ovpn

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

Соберите отредактированную копию для заявки

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

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

Держите сравнение привязанным к отказу

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

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

Похожие статьи