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

Если у клиента дома (или в другом офисе) та же 10.0.10.0/24, что и в целевой LAN, ядро честно отправит пакет в локальный Ethernet, не в wg0/tun0. Handshake при этом может быть идеальным. Лечите адресным планом: перенумеруйте одну из сетей (предпочтительно) или NAT overlapping в уникальный префикс. Не «исправляйте» это AllowedIPs = 0.0.0.0/0 вслепую: сломаете бытовой интернет и не гарантируете доступ к правильному 10.0.10.10.

Проверка одной командой: ip route get 10.0.10.10 — устройство должно быть туннель, не eth0 домашнего роутера.

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

  • VPN Connected, 10.8.0.1 пингуется, 10.0.10.10 отвечает другой хост (домашний NAS) или никто.
  • На Windows метрика LAN ниже, чем у VPN, для того же префикса.
  • IPsec site-to-site: Child не встаёт / TS_UNACCEPTABLE, потому что оба конца объявили одну сеть.

Не путать с отсутствием маршрута вообще (маршруты) и с forwarding (LAN): там route get уже смотрит в туннель.

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

  1. Домашний DHCP раздал 10.0.10.0/24, офис такой же.
  2. Два филиала с копипастой адресного плана.
  3. Docker/WSL/10.0.0.0/8 на ноутбуке пересекается с 10.8.0.0/24 или LAN.
  4. IPsec TS одинаковые с обеих сторон.
  5. Второй NIC (Wi-Fi + Ethernet) в ту же подсеть.
  6. Попытка split tunnel на 10.0.10.0/24 при connected LAN в той же сети.

Диагностика

1. Откуда пакет

Linux:

ip addr
ip route get 10.0.10.10
ip route show | grep 10.0.10
wg show

Windows 11:

Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.0.10.*'
Find-NetRoute -RemoteIPAddress 10.0.10.10 | Format-List
Get-VpnConnection

Если InterfaceAlias — Wi-Fi, не VPN — overlapping.

2. Кто отвечает

ping -c 1 10.0.10.10
ip neigh show 10.0.10.10

MAC домашнего роутера vs ожидаемый сервер — доказательство.

3. Туннель жив отдельно

ping -c 2 10.8.0.1
tcpdump -n -i wg0 host 10.0.10.10

Тишина на wg0 при ping «в офис» — пакет не в туннель.

Решение

Сценарий A. Перенумеровать домашнюю сеть (лучший для сотрудника)

На домашнем роутере смените LAN на незанятый префикс, например 10.20.30.0/24 (проверьте, что не пересекается с 10.8.0.0/24 и офисом). Обновите DHCP. VPN-шаблон не трогайте. Это правильный фикс для «у всех дома 10.0.10.0/24».

Сценарий B. Перенумеровать офис

Если офис маленький и ещё можно: выберите уникальный RFC1918, обновите DHCP, VPN AllowedIPs/TS, DNS A-записи, GPO. Чеклист длинный — AD, принтеры, ACL. Не делайте половину хостов в старой сети.

Сценарий C. NAT overlapping на VPN-шлюзе

Офис остаётся 10.0.10.0/24. Клиентам публикуете другой префикс, например 10.90.10.0/24, который DNAT в 10.0.10.0/24 на шлюзе. Клиентский AllowedIPs / route — 10.90.10.0/24, не 10.0.10.0/24.

Пример идеи iptables (адаптируйте интерфейсы):

iptables -t nat -A PREROUTING -i wg0 -d 10.90.10.0/24 -j NETMAP --to 10.0.10.0/24
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 10.0.10.0/24 -o eth1 -j MASQUERADE

NETMAP требует соответствующего модуля; альтернатива — 1:1 DNAT на конкретные хосты (RDP-бастион), что для подрядчика часто достаточнее полной сети. Документируйте: «RDP на 10.90.10.10 = 10.0.10.10».

Сценарий D. IPsec site-to-site

Одинаковые TS не заработают. Либо перенумерация филиала, либо policy NAT до инкапсуляции (NAT тогда до IPsec на одном конце). Не расширяйте TS до 0.0.0.0/0 как замену плану.

Сценарий E. Docker/WSL

Сдвиньте Docker bip/WSL NAT, если они едят 10.8.0.0/24. Конфликт с туннельным префиксом даёт ту же картину, что overlapping LAN.

Стенд: два DHCP с одним префиксом

Клиент: Wi-Fi дома 10.0.10.50/24, VPN AllowedIPs 10.0.10.0/24. ip route get 10.0.10.10 → dev wlan0. На wg0 тишина при ping. Смените домашний LAN на 10.33.0.0/24, не трогая офис, и повторите: dev wg0. Это доказательство overlapping, его приложите в заявку «VPN сломан» до перенумерации офиса.

Windows:

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -eq '10.0.10.0/24' |
  Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric, ifIndex

Две строки On-link и VPN — смотрите метрику и connected. Connected почти всегда победит.

Для site-to-site не лечите это 0.0.0.0/0 на филиале: интернет филиала уедет в центр, а конфликт /24 останется как connected. Только NAT до IPsec или новая адресация. Документируйте NAT-префикс 10.90.10.0/24 в DNS отдельной зоной или view, иначе пользователи снова набьют 10.0.10.10 в RDP и попадут на домашний роутер.

Проверка NAT-префикса на клиенте Windows

Если офис остаётся 10.0.10.0/24, а клиенту отдан 10.90.10.0/24, в RDP указывайте 10.90.10.10. Запись DNS pc01.contoso.example → 10.0.10.10 снова отправит пакет в домашний On-link. Для пилота заведите pc01.vpn.contoso.example → 10.90.10.10 или NRPT только для этой зоны. Get-VpnConnection здесь не поможет: это не split, это карта имён.

Resolve-DnsName pc01.contoso.example
Find-NetRoute -RemoteIPAddress 10.90.10.10
Find-NetRoute -RemoteIPAddress 10.0.10.10

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

ip route get 10.0.10.10
# или для NAT-префикса:
ip route get 10.90.10.10
ping -c 2 10.8.0.1

dev — VPN-интерфейс. Ответчик — офисный хост (проверьте имя/роль), не домашний роутер. tcpdump -i wg0 видит ICMP/TCP.

Windows: Find-NetRoute на целевой префикс → VPN adapter.

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

  • Маршрут в туннель есть, ответов нет — forwarding, статья LAN.
  • NAT есть, DNS отдаёт старые 10.0.10.x — поправьте DNS или hosts/NRPT на NAT-префикс, иначе приложения пойдут локально.
  • Только IPv6 ULA совпал — смотрите IPv6 table отдельно.

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

  • Адресный план компании: туннель 10.8.0.0/24, офис уникален, домашний гайд «не используйте офисный префикс».
  • В инструкции VPN: «если дома 10.0.10.0/24 — смените LAN роутера».
  • Не копировать 192.168.0.0/24 во все филиалы.
  • Инвентарь пересечений до включения site-to-site.

FAQ

Почему AllowedIPs 10.0.10.0/24 не побеждает локальную сеть?

Зависит от метрик и того, как ОС ставит connected route (/24 connected обычно сильнее). Connected LAN выигрывает у «allowed ips».

Full tunnel спасёт?

0.0.0.0/0 может увести default, но connected 10.0.10.0/24 часто всё равно локальный. Не полагайтесь.

Можно ли просто сменить IP сервера в DNS на 10.8.0.x?

Только если сервер реально слушает туннель. Обычно нет. Лучше NAT или перенумерация.

Два офиса, оба 10.0.10.0/24, нужен mesh

Без NAT или перенумерации IPsec TS не построить честно. Это проект адресации, не «ещё один conn».

Это и есть локальная подсеть. Пока On-link на Wi-Fi, VPN сюда не вклинится.