danyaaaadrain, У вас похоже треугольный (асимметричный) роутинг. Если вы пингуете сеть 192.168.1.0/24 с машины, которая находится в сети 192.168.0.0/24, то это так не работает - ответы отбрасываются, так как они приходят непосредственно с 192.168.0.4, а не оттуда, откуда их ждет машина посылающая запросы (от ростелекомовского роутера). Нужно либо делать SNAT на 192.168.0.1, либо прописывать маршруты на машинах в сети 192.168.0.0/24 вручную, или через DHCP
Ziptar, Longest prefix match - универсальное правило, хоть на MacOS, хоть на винде. Работает всегда более специфический маршрут. У вас может быть маршрут on-link в 192.168.0.0/24 и рядом с ним маршрут в 192.168.0.254/32 через VPN. Это разные подсети с точки зрения FreeBSD и большая маска всегда решает. Трафик к 192.168.0.254 пойдет через VPN
Ziptar, Не работаю с MacOS, но, учитывая ее родную бабушку FreeBSD, могу предположить, что нет, не может быть 2 маршрута в одну сеть с разными приоритетами. Во FreeBSD нет метрик маршрутов, по моей памяти. Там для представления таблицы маршрутизации используется trie, что не предполагает таких выкрутасов. Могло конечно все измениться за годы. Чистое ИМХО
Предполагаю, что MacOS видит у себя on-link маршрут в 192.168.0.0/24 и игнорирует пуши, ломающие маршрутизацию и отключающие ее от ее собственной локальной сети.
У шлюза есть ARP-кэш - он просто смотрит какой MAC у IP и шлет обратный трафик в нужный интерфейс. Клиенты ведь идут в интернет через шлюз и неизбежно попадают в этот кэш.
Сценарий, при котором нужной записи нет в кэше - редкость. Например, если на шлюзе настроен проброс порта на хост в локальной сети и шлюз должен сам узнать MAC хоста по IP, так как, чисто теоретически, нужной записи в кэше может и не быть. В этом случае недостаточно настроить клиентов, на шлюзе тоже придется прописать on-link маршрут в подсеть клиента.
