Нужна ли каждому пиру OpenVPN строка remote? Не совсем

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

Что на самом деле задаёт remote

Запись remote называет хост, необязательно порт и транспорт, а также необязательно несколько таких записей, которые пробуются по порядку.

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

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

Ответ определяют три схемы

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

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

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

Роли транспорта — другая ось

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

Существует также роль фильтра источника TCP, поэтому плоское утверждение, что сервер никогда не может содержать remote, неверно.

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

Почему отсутствие remote — не открытая дверь

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

Аутентификация и адрес назначения независимы, и для доверия важно первое.

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

Запишите, что предполагает конфигурация

Для каждой стороны запишите три вещи: как первый пакет достигает пира, какая сторона может принять транспорт и что каждая сторона проверяет у другой.

Эти допущения и есть проект. Директивы — лишь их написание.

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