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

«Нет маршрута» значит: стек не знает next-hop для префикса или next-hop недостижим. В схеме LAN 10.0.10.0/24, шлюз 10.0.10.1. До интернета нужен default via 10.0.10.1. До филиала 10.0.20.0/24 — либо тот же шлюз (если он знает путь), либо маршрут в VPN-интерфейс. Снимите таблицу до route -p. Не плодите постоянные маршруты поверх DHCP.

Таймаут ping — часто фильтр. Мгновенный Network is unreachable / Destination net unreachable — таблица.

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

  • ping 10.0.20.10 сразу «unreachable», ping 10.0.10.1 жив;
  • tracert не показывает даже первый хоп;
  • Ubuntu: connect: Network is unreachable.

Отличия:

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

  1. Нет default и нет конкретного маршрута в 10.0.20.0/24.
  2. DHCP не дал option 3 / его перетёрла статика.
  3. VPN поднялся без routes (split-tunnel без префикса филиала).
  4. Метрика default через Wi‑Fi ниже, чем через нужный NIC.
  5. Next-hop 10.0.10.1 не ARP-ится.
  6. Политика NRPT/ICS удалила маршруты.
  7. На сервере Ubuntu забыли ip route add после netplan.
  8. VRF/таблица 220 (policy routing) мимо main.

Диагностика

Методика: ping, tracert, nslookup плюс таблица.

1. Снимок таблицы

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric, DestinationPrefix | Format-Table DestinationPrefix, NextHop, RouteMetric, InterfaceAlias
Get-NetIPConfiguration
Find-NetRoute -RemoteIPAddress 10.0.20.10
ip route
ip route get 10.0.20.10
ip route get 1.1.1.1

RTNETLINK answers: Network is unreachable на ip route get — нет подходящего префикса.

2. Default vs specific

Нужен ли интернет или филиал? Для 10.0.20.10:

  • совпал 0.0.0.0/0 via 10.0.10.1 — дальше проблема уже на шлюзе (у него нет маршрута) или ACL;
  • совпал on-link из-за /8 — маска;
  • совпал VPN 10.0.20.0/24 — смотрите туннель UP.

3. Next-hop жив

ping -n 4 10.0.10.1
arp -a 10.0.10.1
Test-NetConnection 10.0.20.10
tracert -d 10.0.20.10
ping -c 4 10.0.10.1
traceroute -n 10.0.20.10

Если Find-NetRoute говорит via 10.0.10.1, а traceroute умирает на первом хопе — маршрут у клиента есть, копайте шлюз.

4. На шлюзе Ubuntu 10.0.10.1

ip route
ip route get 10.0.20.10 from 10.0.10.10 iif eth0
sudo nft list ruleset

Нет 10.0.20.0/24 и нет default в сторону филиала — добавьте маршрут/VPN здесь, не на каждом ПК.

5. VPN

Get-VpnConnection
Get-NetRoute | Where-Object InterfaceAlias -Match 'VPN|Wintun|wg'
ip link show type wireguard
wg show
ip route | grep 10.0.20

Туннель UP без префикса 10.0.20.0/24 — типичный split-tunnel miss.

Решение

Сценарий A. Нет default на клиенте

DHCP option 3 = 10.0.10.1 или netplan default. Не route add 0.0.0.0 навсегда на ноутбуке, который ходит в разные сети.

Сценарий B. Филиал должен идти через шлюз LAN

На 10.0.10.1 маршрут в 10.0.20.0/24 через нужный next-hop/туннель. Клиентам ничего не добавляйте: достаточно default/connected.

Сценарий C. Split-tunnel

Добавьте 10.0.20.0/24 в AllowedIPs/split list VPN. Проверьте, что не перекрыли 10.0.10.0/24 (локальная сеть) более широким 10.0.0.0/8.

Сценарий D. Точечный маршрут на одном сервере

Ubuntu:

sudo ip route add 10.0.20.0/24 via 10.0.10.1

Постоянно — в netplan routes:. Windows:

New-NetRoute -DestinationPrefix '10.0.20.0/24' -NextHop 10.0.10.1 -InterfaceIndex 12

InterfaceIndex свой из Get-NetIPConfiguration.

6. Где должна жить строка маршрута

Клиент в 10.0.10.0/24 для филиала 10.0.20.0/24 обычно не должен иметь собственной статики, если 10.0.10.1 уже маршрутизирует. Сначала Find-NetRoute / ip route get 10.0.20.10. Если via 10.0.10.1 — проблема на шлюзе (нет префикса, ACL, VPN). Если Network unreachable — нет default и нет specific, чините таблицу клиента/DHCP option 3. Если via VPN-интерфейс, а туннель down — не пишите route -p на LAN NIC «чтобы заработало».

На шлюзе Ubuntu:

ip route get 10.0.20.10 from 10.0.10.10 iif eth-lan
ping -c 3 10.0.20.10

Нет маршрута — добавьте на шлюзе, не на двадцати ПК. Split-tunnel: AllowedIPs без 10.0.20.0/24 даёт ровно «VPN подключен, шары филиала нет». Не публикуйте 10.0.0.0/8, если офис /24: сломаете on-link до 10.0.10.2. Перед persistent route на Windows — PersistentStore inventory, план Remove-NetRoute. Проверка: traceroute первый хоп ожидаемый, плюс TCP до реального сервиса, не только ICMP, который филиал может фильтровать.

Методика трёх инструментов здесь вторична, но обязательна после появления маршрута: ping 10.0.20.10 может быть запрещён, тогда Test-NetConnection -Port. Unreachable vs timeout запишите буквально: от этого зависит, идёте ли вы в таблицу или в ACL. На клиенте с двумя NIC (LAN+VPN) снимите оба default и specific до правок. Метрика VPN ниже LAN при полном туннеле спрячет филиальный /24 за 0.0.0.0/0 в туннель — иногда это задумано, иногда нет. Get-NetRoute -PolicyStore PersistentStore ищите до добавления ещё одной постоянной строки. Ubuntu ip rule может отправлять 10.0.20.10 в таблицу, которой нет — тогда ip route main врёт вам «всё хорошо». Не делайте ip route flush на шлюзе. Откат: консоль, заранее ip route save / сохранённый netplan. Когда филиал зажил, проверьте обратный ping с 10.0.20.10 в 10.0.10.10: односторонний маршрут — следующая статья про асимметрию, не «ещё раз добавим route на ПК».

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

Find-NetRoute -RemoteIPAddress 10.0.20.10
ping -n 4 10.0.20.10
tracert -d 10.0.20.10
nslookup contoso.example 10.0.10.2
ip route get 10.0.20.10
ping -c 4 10.0.20.10
traceroute -n 10.0.20.10

Первый хоп ожидаемый (10.0.10.1 или VPN). Обратный ping с узла филиала. Не только ICMP: Test-NetConnection 10.0.20.10 -Port 445 если это файл-сервер.

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

  • Маршрут есть, NAT не выпускает — NAT не для всех.
  • Policy routing по mark обходит main.
  • IPv6 default жив, IPv4 нет — приложение берёт AAAA.
  • Метрика: два default, трафик уходит не туда.

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

  • Маршруты филиалов на шлюзе/VPN, не на каждой рабочей станции.
  • Инвентаризация persistent routes.
  • Мониторинг ip route get до префиксов филиала.
  • Документ: какой префикс через какой туннель.

FAQ

Unreachable vs timeout?

Unreachable — нет маршрута или нет ARP до next-hop. Timeout — пакет ушёл, ответа нет. Разные статьи.

Добавить 10.0.20.0/24 на каждый ПК?

Нет, если шлюз 10.0.10.1 и так маршрутизирует. Исключение: split-tunnel VPN на самом ПК.

Почему ping 10.0.10.2 есть, 10.0.20.10 нет?

10.0.10.2 connected. Удалённая сеть требует маршрута за шлюзом. Это ожидаемо.

ip route flush на Ubuntu-сервере?

Нужен ли tracert, если route get уже пустой?

route get достаточ для «нет в таблице». traceroute полезен, когда таблица есть, а путь ломается дальше.