Клиенты нижестоящей сети за вышестоящим VPN: маршрут или NAT?

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

Решите модель возврата, прежде чем трогать маршрутизацию

В этом разборе клиенты нижестоящей сети используют 10.90.0.0/24, выданный шлюзу адрес вышестоящего туннеля — 10.80.0.6, а разрешённый удалённый ресурс — 172.20.0.30. Этой схеме соответствуют две модели: сохранить нижестоящий источник и заставить дальнюю сторону его маршрутизировать либо преобразовать источник в собственный адрес туннеля шлюза. Всё после этого решения механично, а само решение требует владельца сервиса. Одна из строк выше — соглашение о маршрутизации с дальней стороной; другая — локальное изменение политики, которое вы можете сделать сами. Именно путаница между ними превращает десятиминутное изменение в переговоры.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Выберите одну строку и держитесь её. Строки — это альтернативы, а не шаги, и их смешение даёт проект, который никто не сможет объяснить на проверке.

Сохранение источника с маршрутизацией

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

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

Намеренное преобразование источника

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

IPv6 требует собственного проекта; копирование строки masquerade для IPv4 — не архитектура. Проверяйте преобразованный путь новым соединением, а не закэшированным.

Локальный путь данных всё равно должен работать

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

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

Один источник означает одну идентичность сеанса

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

Запишите это подтверждение в runbook рядом с правилом, потому что следующий проверяющий спросит, был ли проект утверждён или просто удобен.

Определите состояние разрыва, затем проверьте три запроса

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

Запишите откат одной строкой на правило, чтобы изменение можно было отменить, не восстанавливая замысел.