Коротко: это обычная задача «подключить подсеть за клиентом к VPN». Нужны либо маршрутизация (routed VPN) + включённый форвардинг на удалённом клиенте, либо L2‑бридж (tap), если устройство «живёт» только в link‑local/L2. Ниже — пошагово как сделать через маршрутизацию (рекомендуемый вариант).
1) Определите точную сеть, которую надо анонсировать
- У вас устройство с адресом 169.254.X.Y/255.255.255.0 — значит сеть 169.254.X.0/24 (APIPA по умолчанию /16, но вы писали mask 255.255.255.0). Используйте правильную маску/сеть при настройке.
2) На OpenVPN‑сервере (routed mode) — объявить маршрут
- В server.conf добавьте (пример для /24):
route 169.254.<X>.0 255.255.255.0
- Убедитесь, что у вас включен client‑specific configuration directory:
client-config-dir /etc/openvpn/ccd
(и это директива уже включена в конфиг сервера)
3) В ccd создайте файл с именем CommonName клиента 10.8.0.3 (имя, которым он аутентифицируется, см. в сертификате)
- В /etc/openvpn/ccd/<ClientCN> добавьте строку:
iroute 169.254.<X>.0 255.255.255.0
(iroute сообщает OpenVPN‑серверу, что эта подсеть доступна за данным клиентом)
4) Включите IP‑форвардинг на самом клиенте (Windows)
- На Windows нужно разрешить маршрутизацию:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v IPEnableRouter /t REG_DWORD /d 1 /f
Затем перезагрузите машину (или перезапустите соответствующие службы).
- Проверьте firewall: разрешите пересылку пакетов между VPN‑адаптером и локальным интерфейсом (разрешите входящие ICMP/TCP/UDP как нужно). Иногда проще временно отключить Windows Defender Firewall для теста.
5) Перезапустите OpenVPN‑сервер и переподключите клиента 10.8.0.3
- После перезапуска сервер разошлёт маршрут другим клиентам (через push) и будет знать, что сеть 169.254.<X>.0 уходит к клиенту <ClientCN>.
6) Проверки и отладка
- На сервере: ip route show (Linux) — должна быть запись route 169.254.<X>.0 via 10.8.0.3 (у OpenVPN сервер знает куда направлять).
- На клиенте 10.8.0.2: route print (Windows) или ip route show — должна появиться маршрут к 169.254.<X>.0 через 10.8.0.3; если нет, можно временно добавить вручную:
route ADD 169.254.<X>.0 MASK 255.255.255.0 10.8.0.3
- Пингуйте целевое устройство 169.254.X.Y с 10.8.0.2.
- Если не отвечает — на 10.8.0.3 с помощью tcpdump/Wireshark посмотрите, доходят ли пакеты с VPN интерфейса к локальному интерфейсу, и видит ли само устройство ответы.
7) Важные замечания
- APIPA (169.254.0.0/16) — по стандарту link‑local. Большинство протоколов IP нормально маршрутизируется, так что routing работает. Но некоторые устройства/сервисы ожидают L2 соседство / ARP/броадкасты; в этом случае нужен мост (tap) и L2‑бриджинг удалённого интерфейса в VPN. Это сложнее и менее масштабируемо.
- Если не хотите трогать сервер/ccd, можно временно на клиенте 10.8.0.2 добавить статический маршрут:
route ADD 169.254.<X>.0 MASK 255.255.255.0 10.8.0.3 -p
Но это локальное (нескалируемое) решение.
- Альтернатива — NAT на клиенте 10.8.0.3 (маскарадинг локальной 169.254 адреса в 10.8.0.3), тогда не нужно iroute/route; но на Windows это менее удобно (требуется RRAS или сторонние инструменты).
Если хотите — пришлите:
- полный /etc/openvpn/server/server.conf,
- содержимое /etc/openvpn/ccd (если есть),
- Common Name клиента 10.8.0.3,
— и я покажу точные строки для добавления и проверочные команды под Ubuntu 24 и Windows 10/11.