Экспорт из Viscosity против простого профиля OpenVPN в Linux

Переименование файла Viscosity .visz в .ovpn не меняет содержимое, потому что расширение никогда не описывало протокол. Важное сравнение — между пакетом с зависимостями и обычным профилем клиента без них. Определите, какой контейнер вы действительно получили, прежде чем просить импортёр в Linux его прочитать.

Что содержит каждый контейнер

Документация по экспорту Viscosity описывает пакет подключения .visc и архивную форму .visz, которая является сжатым tar-архивом. Пакет несёт конфигурацию вместе с файлами сертификата, ключа и скриптов, от которых он зависит. Обычный профиль OpenVPN — это один файл, и всё, на что он ссылается, должно существовать отдельно или быть встроено внутрь.

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

Внешнее расширение говорит, какой контейнер у вас есть, а не какой клиент может его использовать.

Где конфигурация действительно начинается

Внутри пакета поставщик документирует config.conf рядом с зависимыми файлами, а ссылки разрешаются локально. Этот файл — отправная точка, а не имя архива и не тот сертификат, который случайно оказался вверху списка каталога.

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

Удаление опции доверия или идентичности, чтобы заглушить эту жалобу, — не исправление.

Чего пакет не переносит

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

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

Оригинал остаётся защищённым, пока миграция не принята.

Что должна решить сторона Linux

Решите, кто будет владеть подключением: Community OpenVPN сам по себе, плагин NetworkManager или другой поддерживаемый клиент. Каждый принимает свой набор опций, и каждый по-своему управляет маршрутами, резолверами и секретами. Файл, который успешно открывается в одном импортёре, может быть отвергнут другим, и успех при импорте не доказывает совместимость с предполагаемым подключением. Спросите оператора, существует ли уже профиль, совместимый с Linux, потому что начать с поддерживаемого артефакта короче, чем переводить его.

Держите доверие к серверу, идентичность клиента и защиту закрытого ключа как три отдельных вопроса.

Проверка перед подключением

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

openvpn --config ./config.conf --verb 4

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

Когда миграция принята, выведите передаточные копии из обращения обычным процессом работы с учётными данными. Пакет, оставленный в общей папке, — это учётные данные, оставленные в общей папке.