Почему копирование конфигурации сервера OpenVPN в филиал не работает

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

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

Две роли, которые выглядят как один файл

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

Файл сервера содержит директивы, которые не имеют смысла на клиенте: адрес привязки и порт для прослушивания, пул адресов для выдачи и часто список выталкивания настроек, которые клиенты должны получать. Копирование их в филиал порождает устройство, которое пытается быть и слушателем, и клиентом одновременно.

Закрытый ключ — самая важная часть. Клиент никогда не должен носить закрытый ключ сервера, и ключ подписи CA ему тоже не нужен. Сертификат CA — публичный материал доверия; ключ подписи принадлежит туда, где выпускаются сертификаты.

Что должен содержать профиль филиала

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

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

Будьте осторожны с рабочими процессами устройств. Пакет Client Export в pfSense создаёт профили для подходящих контекстов Remote Access, и его список серверов включает только серверы, настроенные в режиме Remote Access. Сервер «площадка—площадка» другого режима не появляется, и это отсутствие — информация, а не приглашение копировать секреты сервера.

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

Связка партнёра с сетью отдельная

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

Добавление маршрута в операционной системе концентратора — не то же самое, что сказать OpenVPN, какой клиент владеет префиксом. Без связки для каждого клиента пакет доходит до интерфейса туннеля и отбрасывается, потому что ни один партнёр не заявляет пункт назначения.

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

Доказать, что филиал — тот партнёр, о котором вы думаете

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

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

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

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