Что это такое?

Это режим работы OpenVPN.

Зачем это нужно?

Для выбора режима "точка-точка" либо "точка-многоточка".

Как это настроить?

p2p

Одноранговый туннель "точка-точка", либо данное устройство работает в качестве клиента в топологии "точка-многоточка".

server

Устройство работает в качестве сервера в топологии "точка-многоточка". Дополнительно можно ограничить число одновременно подключённых клиентов.

ПРИМЕЧАНИЕ. Режим p2p не запрещает, а режим server не обязывает использовать шифрование в режиме tls-client/tls-server. Режим подключения и режим шифрования — не связанные друг с другом сущности. Как правило, серверу логически следует быть одновременно и сервером TLS-шифрования, но это исключительно соображение здравого смысла, а не требование.

ПРИМЕЧАНИЕ. Если переключение режима p2p/server приводит к режиму, несовместимому с выбранным протоколом, то протокол устанавливается в значение по умолчанию (UDP).

Режим "точка-точка" рекомендуется использовать для статичных транзитных маршрутизаторов, соединяющих две сети. В этом режиме настройка IP-адресов и маршрутизации между защищаемыми (приватными) сетями через туннель производится так же, как любого другого канала "точка-точка" и может выполняться либо штатными средствами NSG Linux, либо директивами OpenVPN ifconfig и route (в NSG Linux они могут указываться в поле extra.) Статический адрес открытого (публичного) интерфейса при этом достаточно иметь только на одной из сторон, адрес другой может быть априори неизвестен.

Режим сервера в OpenVPN ориентирован, в первую очередь, на подключение одиночных клиентов, которые являются оконечными хостами (например, ПК удалённых сотрудников). Он по существу требует, чтобы после того, как маршрутизация в ядре Linux направила пакет в интерфейс OpenVPN, внутри подсистемы OpenVPN производился ещё один этап маршрутизации — к конкретному клиенту и обратно. Из этого вытекает ряд логических следствий, не все из которых могут радовать сетевого администратора:

• Сервер должен знать IP-адреса клиентов, а для этого он должен сам их динамически назначать. По форме это требует наличия директивы server (указывается в extra.
• Адреса назначаются клиентам псевдослучайным образом. В каждый текущий момент они, в принципе, предсказуемы, но зависят от порядка подключения/отключения клиентов, который может быть произвольным.
• Все сетевые взаимодействия могут инициироваться только клиентами; со стороны сервера попасть точно на нужного клиента возможно только после того, как удастся каким-то образом узнать вручную его текущий адрес.
• Из-за того, что адреса случайные, для туннелей типа tun невозможна маршрутизация со стороны сервера в сети, расположенные за клиентами. Никак не возможна, ни средствами ядра и общего интерфейса системы, ни с помощью директив OpenVPN. Невозможна даже в том случае, если текущий адрес клиента априори известен однозначно (например, клиент единственный в данном туннеле).
• Маршрутизация на стороне клиентов в сети, расположенные за сервером, может быть задана директивой
      route СЕТЬ МАСКА vpn_gateway
  (обычно её уместно передавать клиентам через push). Штатными средствами системы она не настраивается.

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

1. Режим сервера для центрального шлюза + NAT Masquerading на клиентской стороне туннеля. Рекомендуется для ситуации, когда филиалы имеют относительную автономию. (В частности, это может выражаться в том, что шлюз в каждом филиале администрируется, хотя бы частично, его сотрудниками, а не из центра.) Таким образом, все пользователи филиала выходят в корпоративную сеть под одним адресом, который назначен в данный момент клиенту OpenVPN. Это накладывает следующие ограничения:

   • Локальная сеть каждого филиала имеет собственную схему IP-адресации, не связанную с общим адресным планом корпоративной сети.
   • Все сетевые взаимодействия могут инициироваться только со стороны филиалов.
   • Чтобы попасть из центра на клиента, нужно узнать его текущий адрес. (Например, позвонить в филиал.)
   • Со стороны центра попасть в сеть филиала невозможно. Гипотетически, можно было бы настроить на клиентах Destination NAT для проброса входящих соединений хотя бы на конкретные адреса и порты, но из-за того, что адреса клиентов случайные, практического смысла это не имеет.

2. Режим сервера + туннели типа tap (т.е. эмуляция Ethernet) + динамическая маршрутизация (OSPF или RIP) между сервером и клиентами. В таком сочетании маршрутизация работает. Рекомендуется, если к сети предъявляются требования:

   • Единый адресный план для головного офиса и филиалов.
   • Возможность заходить из центра на произвольные адреса и порты в филиалах.
   • Большое число клиентов и их частое добавление/удаление.

   Типичный пример такой ситуации — сеть банка с большим количеством банкоматов.

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

3. Энное количество индивидуальных туннелей ovpnNUM "точка-точка", по одному в каждый филиал, каждый на отдельном порту UDP или TCP центрального шлюза. Наиболее детерминированный вариант, но наиболее трудоёмкий в настройке. Хотя, с другой стороны, наиболее простой для понимания, поскольку не требует разбираться в отношениях маршрутизации в ядре системы с маршрутизацией внутри OpenVPN. Рекомендуется при следующих условиях:

   • Небольшое и редко меняющееся число филиалов.
   • Возможность заходить из центра на произвольные адреса и порты в филиалах.
   • Единый адресный план для головного офиса и филиалов.

   Для удобства настройки однотипных туннелей рекомендуется воспользоваться соединением %default, предусмотренным в NSG Linux. Это шаблон, в который можно записать параметры, одинаковые для всех или большинства клиентов. Тогда в узлах ovpnNUM явно указываются только параметры, специфичные для данного туннеля (по существу, только номер порта UDP/TCP, IP-адреса и описание).

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