Клиент WireGuard не дотягивается до клиента OpenVPN?

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

В симптоме каждый раз не хватает одной части

Эта схема использует пул WireGuard 10.71.0.0/24 на wg1 и пул OpenVPN 10.72.0.0/24 на tun1, оба заканчиваются на одном шлюзе. Проверяемый запрос идёт с 10.71.0.5 к HTTPS на 10.72.0.30. Каждый шаг ниже относится к одному и тому же потоку. Каждая проверка имеет свою подпись отказа, хотя пользователь переживает их одинаково, и обычно одновременно не хватает лишь одной из трёх.

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

Расширьте покрытие назначения на спице

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

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

Сохраните принадлежность источника на шлюзе

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

AllowedIPs = 10.71.0.5/32

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

Дайте стороне OpenVPN обратный маршрут

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

push "route 10.71.0.0 255.255.255.0"

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

Разрешите ровно ту одну службу, которую собирались разрешить

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Это правила для пересылаемого трафика, отдельные от правил прослушивания шлюза для двух служб VPN. Открытие внешних портов UDP не авторизует внутренний запрос, а авторизация внутреннего запроса не требует неограниченного SSH к шлюзу или разрешения по умолчанию на пересылку. Собственный межсетевой экран назначения и его адрес прослушивания тоже должны совпадать, поскольку служба, привязанная к loopback, отвергает даже самый аккуратно маршрутизированный пакет. Политика, покрывающая только одно направление разговора, обычно отказывает успешным запросом и молчаливым ответом, и это самый запутанный из трёх исходов.

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