Короткий ответ

Если туннель 10.8.0.0/24 пингуется, а хост 10.0.10.10 нет, проблема почти никогда не в ключах. Шлюзу нужен ip_forward, разрешённый FORWARD между VPN-интерфейсом и LAN, и обратный путь: либо маршрут 10.8.0.0/24 на LAN-хостах через VPN-шлюз, либо SNAT/MASQUERADE на выходе в LAN. Клиенту нужен маршрут на 10.0.10.0/24 в туннель (AllowedIPs, pushed route, Add-VpnConnectionRoute).

Не отключайте firewall. Не публикуйте LAN в интернет, чтобы «проверить, что хост жив». Диагностика — с клиента VPN и с самого шлюза.

Симптомы и как отличить

  • VPN «подключён» (WireGuard handshake / IPsec SA / OpenVPN CONNECTED / Windows Connected).
  • ping 10.8.0.1 (адрес шлюза в туннеле) успешен.
  • ping 10.0.10.10 — 100% loss.
  • Иногда ping есть, а TCP 3389/445 нет — тогда это хостовый фильтр, см. RDP через VPN.

Не путать с:

НаблюдениеСмысл
Нет даже ping до 10.8.0.1 на WireGuardAllowedIPs или нет handshake
Интернет пропал целикомdefault route, full tunnel
Пакет уходит в домашний 10.0.10.0/24overlapping
В таблице клиента нет 10.0.10.0/24маршруты не добавляются

Возможные причины

  1. На клиенте нет маршрута 10.0.10.0/24 → VPN-интерфейс.
  2. net.ipv4.ip_forward=0 на Linux-шлюзе.
  3. FORWARD drop (nftables, iptables, UFW, Windows RRAS без статического фильтра «разрешено»).
  4. Хосты LAN отвечают на VPN-шлюз, но не знают, как вернуть пакет на 10.8.0.10 — нет маршрута и нет SNAT.
  5. rp_filter=1 отбрасывает асимметрию.
  6. Политика IPsec Phase 2 / TS не включает 10.0.10.0/24 — SA жива только для 10.8.0.0/24.
  7. OpenVPN без iroute/push "route 10.0.10.0 255.255.255.0" и без client-config-dir.

Диагностика

1. Куда смотрит клиент

Linux:

ip route get 10.0.10.10
ip route show
wg show

Ожидание для split tunnel: 10.0.10.10 dev wg0 (или tun0). Если dev eth0 / домашний шлюз — пакет в офис не пойдёт.

Windows 11:

Get-VpnConnection | Format-List Name, ConnectionStatus, SplitTunneling
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.0.10.*'
Test-NetConnection 10.8.0.1
Test-NetConnection 10.0.10.10

2. Форвардинг на шлюзе

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.all.rp_filter
ip route get 10.0.10.10 from 10.8.0.10 iif wg0

Последняя команда показывает, принял бы Linux пакет с туннеля к LAN. unreachable / RTNETLINK — нет маршрута в LAN или запрет policy routing.

3. Фильтр и NAT

iptables -L FORWARD -n -v
iptables -t nat -L POSTROUTING -n -v
nft list ruleset

Ищите hits на DROP между wg0/tun0 и eth1 (LAN). Нулевые counters при ping с клиента — пакет до фильтра не доходит (маршрут/AllowedIPs/TS).

tcpdump -n -i wg0 host 10.0.10.10
tcpdump -n -i eth1 host 10.0.10.10

Если ICMP виден на wg0 и нет на LAN-интерфейсе — FORWARD/маршрутизация. Если есть на LAN и нет ответа — хост, его firewall или нет обратного маршрута.

4. Обратный путь

С хоста LAN 10.0.10.10:

ip route get 10.8.0.10

Windows-хост:

Find-NetRoute -RemoteIPAddress 10.8.0.10 | Format-List

Если LAN думает, что 10.8.0.0/24 «где-то в интернете» через дефолтный шлюз не-VPN — ответ уйдёт не туда.

Решение

Сценарий A. Клиенту некуда слать LAN

WireGuard: добавьте 10.0.10.0/24 в AllowedIPs клиента. OpenVPN 2.6: push "route 10.0.10.0 255.255.255.0" на сервере или route в client.ovpn. Windows RAS:

Set-VpnConnection -Name 'Office' -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName 'Office' -DestinationPrefix '10.0.10.0/24'

Подключение заново. Проверьте Get-NetRoute.

Сценарий B. ip_forward выключен

sysctl -w net.ipv4.ip_forward=1
echo net.ipv4.ip_forward=1 > /etc/sysctl.d/99-ip-forward.conf
sysctl -p /etc/sysctl.d/99-ip-forward.conf

На Windows RRAS включён IPv4 forwarding в свойствах службы маршрутизации, не «ICS на все NIC».

Сценарий C. FORWARD закрыт

Разрешите только нужную пару:

iptables -A FORWARD -i wg0 -o eth1 -s 10.8.0.0/24 -d 10.0.10.0/24 -j ACCEPT
iptables -A FORWARD -i eth1 -o wg0 -s 10.0.10.0/24 -d 10.8.0.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Для nftables — аналогичные цепочки iifname/oifname. UFW: правила allow in on wg0 to 10.0.10.0/24, не ufw disable.

Сценарий D. LAN не знает 10.8.0.0/24

Предпочтительно: на шлюзе LAN (тот же VPN-сервер, если он default gateway офиса) маршрут уже есть. Если VPN-сервер не шлюз LAN — добавьте на настоящем шлюзе:

ip route add 10.8.0.0/24 via 10.0.10.1

где 10.0.10.1 — IP VPN-сервера в LAN. Альтернатива, если маршруты на LAN не контролируете:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 10.0.10.0/24 -o eth1 -j MASQUERADE

Хосты увидят источник как VPN-сервер. Это хуже для аудита, но работает. Не маскарадьте в WAN.

Сценарий E. IPsec TS без LAN

Phase 1 может быть UP, а интерес 10.0.10.0/24 не в SA. Сверьте селекторы, см. Phase 2.

Как проверить, что проблема устранена

С VPN-клиента:

ping -c 3 10.8.0.1
ping -c 3 10.0.10.10
ip route get 10.0.10.10
Test-NetConnection 10.0.10.10 -Port 22

На шлюзе tcpdump на LAN-интерфейсе показывает ICMP/TCP к 10.0.10.10 и ответы. sysctl net.ipv4.ip_forward = 1. Counters FORWARD растут в обе стороны.

Если не помогло

  • Один хост LAN отвечает, другой нет — firewall на хосте или изоляция VLAN, не VPN.
  • Имя fileserver.contoso.example не резолвится, по IP работает — DNS через VPN.
  • Домашняя сеть тоже 10.0.10.0/24 — overlapping, не forwarding.
  • Ping есть, RDP нет — NLA и профиль firewall на целевом ПК.

Профилактика

  • Чеклист ввода VPN-шлюза: forward, FORWARD, маршрут 10.8.0.0/24 в LAN или SNAT, push/AllowedIPs LAN.
  • Не использовать одну RFC1918-подсеть и дома, и в офисе.
  • Мониторинг ping с «канарейки» в туннеле до эталонного хоста LAN.
  • Документировать, является ли VPN-сервер default gateway LAN.

FAQ

Почему ping до шлюза VPN есть, а до сервера LAN нет?

Потому что первый остаётся на интерфейсе туннеля. Второй требует маршрутизации в другую L3-сеть и обратного пути.

Обязателен ли MASQUERADE?

Нет, если LAN умеет маршрутизировать 10.8.0.0/24 на VPN-сервер. SNAT — костыль, когда вы не владеете маршрутами офиса.

ip_forward включил, всё равно drop

Смотрите фильтр и rp_filter, не sysctl повторно. ip_forward=1 не обходит nftables drop.

Windows-клиент видит «подключено», маршрута нет

SplitTunneling без Add-VpnConnectionRoute оставляет только туннельный префикс. Добавьте маршрут или выключите split, понимая цену full tunnel.

Безопасно ли разрешить FORWARD any-any?

Нет. Только 10.8.0.0/24 ↔ согласованные LAN-префиксы, плюс ESTABLISHED обратно.