Короткий ответ
«Нет маршрута» значит: стек не знает 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.
Отличия:
- Default нет и интернета нет — есть IP, нет интернета.
- Connected врёт из-за маски — маска.
- Туда пакеты идут, обратно другим путём — асимметрия.
- Таблица верная, hop drop — потери.
Возможные причины
- Нет default и нет конкретного маршрута в
10.0.20.0/24. - DHCP не дал option 3 / его перетёрла статика.
- VPN поднялся без routes (split-tunnel без префикса филиала).
- Метрика default через Wi‑Fi ниже, чем через нужный NIC.
- Next-hop
10.0.10.1не ARP-ится. - Политика NRPT/ICS удалила маршруты.
- На сервере Ubuntu забыли
ip route addпосле netplan. - 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.10ip route
ip route get 10.0.20.10
ip route get 1.1.1.1RTNETLINK answers: Network is unreachable на ip route get — нет подходящего префикса.
2. Default vs specific
Нужен ли интернет или филиал? Для 10.0.20.10:
- совпал
0.0.0.0/0via10.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.10ping -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 12InterfaceIndex свой из 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.2ip 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 полезен, когда таблица есть, а путь ломается дальше.