Почему route -interface не достигает хоста за пределами канала

route принимает имя Wi-Fi-интерфейса, завершается без жалоб, а хост остаётся недоступным. Ничего не повреждено; связь в маршруте просто неверна: флаг интерфейса говорит, на каком канале находится назначение, а не какой маршрутизатор должен получать трафик для назначения, находящегося в другом месте. Команда успешна потому, что синтаксически корректна, а не потому, что описывает работающий путь.

Это различие решает, будет ли исключение маршрута рядом с VPN работать или лишь выглядеть правдоподобно.

Интерфейс — это выход, следующий переход — это передача

На Mac с адресом 192.168.50.20 и маршрутизатором на 192.168.50.1 другая машина в том же канале доступна напрямую. Кадр адресуется этой машине и помещается на кабель. Маршрутизатор не участвует, и маршрут, ограниченный интерфейсом, выражает именно это. Измените дальний конец на хост в другом здании, и та же команда теряет смысл. У Mac нет адреса второго уровня, чтобы поместить его на кабель, поэтому флагу интерфейса нечего описывать.

Назначение за пределами канала — другое. Mac не может поместить на кабель кадр, адресованный хосту, до которого не доходит на втором уровне; он передаёт пакет маршрутизатору, который может. Поэтому маршруту нужен шлюз, и сам шлюз должен быть доступен в подключённом канале.

Использование флага интерфейса для назначения за пределами канала говорит macOS обращаться с этим назначением так, будто оно находится на кабеле. Тогда ядро не может разрешить для него адрес второго уровня, и пакет отбрасывается без чего-либо полезного в ошибке.

Что на самом деле утверждает флаг интерфейса

Справочник по маршрутам Apple определяет форму с интерфейсом для назначений, доступных напрямую без посредника. Это утверждение о модели канала, а не предпочтение о том, какой адаптер использовать. Достижение интернет-хоста через Wi-Fi по-прежнему требует маршрутизатора в этом Wi-Fi-канале, и маршрут должен его назвать.

Область интерфейса — отдельный атрибут. Она связывает маршрут с определённым интерфейсом для решений об области, например какой адрес источника применяется, но не создаёт доступности для назначения, до которого интерфейс сам не доходит. Два атрибута отвечают на разные вопросы.

Поэтому команда может быть принята, появиться в таблице и всё равно не сработать. Ядро не проверяет ваше намерение; оно записывает то, что вы утверждали, а утверждением было то, что назначение находится в канале. Тихий успех, за которым следует тихое отбрасывание, — ожидаемый результат, а не дефект. Перечитайте утверждение, прежде чем винить сеть.

Маршрут, который нужен назначению за пределами канала

Для одобренного пути к адресу документации, например 198.51.100.25, через LAN-маршрутизатор предполагаемая связь — это назначение, следующий переход 192.168.50.1 и LAN-интерфейс, который достигает этого следующего перехода. Интерфейс подразумевается поиском следующего перехода, а не навязывается командой маршрута.

В macOS проверка только для чтения — route -n get 198.51.100.25. Читайте строки шлюза и интерфейса вместе и проверьте, что шлюз — это адрес, до которого Mac действительно доходит. Шлюз в другой подсети или тот, что исчез после последнего изменения сети, даёт маршрут, который выглядит правильным и ничего не пересылает.

Не вписывайте en0 жёстко в долговременную инструкцию. Имена интерфейсов меняются с адаптерами, доками и VPN-клиентами, а маршрут, называющий неправильный, сбоит так, что это легко принять за более широкую сетевую неисправность.

Прочитайте текущий выбор, прежде чем его заменить

Прежде чем что-либо добавлять, изучите, что система уже выбрала и почему. Этот вывод говорит, идёт ли трафик через туннель, через LAN-маршрутизатор или никуда, и даёт базовую линию для сравнения после изменения. Без него вы не можете сказать, подействовал ли новый маршрут.

Затем проверьте семейство адресов. Маршрут, добавленный для IPv4, ничего не делает для назначения IPv6, а служба, которая разрешается в оба семейства, может казаться периодически доступной. Таблица маршрутов и резолвер отвечают на разные вопросы, и обе должны согласовываться с намеченным путём.

Наконец, помните, что маршрут — это выбор, а не разрешение. Управляемый профиль VPN или клиентский фильтр всё ещё может запретить прямой путь, даже когда таблица указывает на него, поэтому проверяйте на реальном приложении, а не предполагайте, что успешная запись в таблице завершает расследование.

Туннели и политика меняют форму

Интерфейсы «точка-точка» — отдельный случай. Туннель может нести маршрут без адреса шлюза в стиле Ethernet, и это не обязательно неправильно. Применяйте реальную модель канала интерфейса, вместо того чтобы распространять пример с Wi-Fi на каждую запись в таблице, которую видите.

Для запросов на изменение запишите назначение, одобренный сетевой путь, текущие шлюз и интерфейс, а также кто должен поддерживать исключение. Владелец важен, потому что разовый маршрут, набранный в приглашении, не является политикой, и следующее переподключение его сотрёт.

Если требование — достигать этого хоста при включённом VPN, честный ответ обычно конкретный маршрут к хосту через локальный маршрутизатор, установленный сетевым менеджером, которому принадлежит интерфейс. Если требование — достигать чего угодно напрямую, само требование нуждается в пересмотре политики раньше, чем в команде маршрута.