Проверка маршрута VPN в macOS: route get без каких-либо изменений

Пользователь попадает в интранет в офисной сети, а не через туннель, хотя Настройки по-прежнему показывают VPN подключённым. Редактирование таблицы маршрутов в этот момент рискует оборвать удалённый сеанс, который вы используете для диагностики. Вместо этого спросите ядро, какой путь оно выберет для сбойного хоста. В утилите route в macOS есть операция get, которая отвечает именно на это для одного адресата, ничего не меняя.

Спрашивайте сбойный хост, а не маршрут по умолчанию

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

Форма — route -n get, за которым следует адрес: route -n get 203.0.113.10, где документационный адрес заменяет вашу цель. Используйте авторизованный адресат и соответствующее семейство адресов, потому что ответ IPv4 ничего не говорит о ресурсе только с IPv6. Документация утилиты route описывает операцию get и поля, которые она выводит.

Читайте интерфейс и шлюз как доказательство

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

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

Правильный маршрут — ещё не работающий запрос

Маршрут говорит, какой интерфейс использовало бы ядро, и ничего больше. DNS, межсетевой экран хоста и авторизация приложения стоят над этим решением, и запрос может завершиться неудачей после успешной маршрутизации. Сохраните точный симптом, прежде чем двигаться дальше, потому что «не удаётся подключиться» и «подключается, но возвращает ошибку» — разные расследования с разными следующими шагами. Представление резолвера и представление интерфейса дополняют запрос к адресату, а не заменяют его.

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

Держите конечную точку и ресурс врозь

Задействованы два поиска, и они отвечают на разные вопросы. Достижение конечной точки — это внешнее путешествие через физическую сеть. Достижение приложения происходит внутри туннеля, по адресу, который существует только на частной стороне. Смешение этих двух порождает классический ложный цикл, в котором конечная точка как будто маршрутизируется через туннель, который она завершает. Запросите оба адреса по отдельности, пометьте каждый результат, и путаница исчезнет.

Перекрытие префиксов — другой случай, который стоит знать. Когда локальные и удалённые диапазоны перекрываются, решает совпадение самого длинного префикса, поэтому перекрывающаяся локальная подсеть может заслонить ожидаемый удалённый адрес. Тогда частный адресат выглядит так же, как локальный, и исправление относится к плану адресации, а не к таблице маршрутов. Запрос get показывает, какой интерфейс победил, и это тот факт, который нужен вам перед любым изменением.

Сначала читайте, потом меняйте

Держите route add и route delete вне первого прохода. На Mac, которым вы управляете удалённо, одна небрежная правка таблицы может отнять именно путь назад к машине, и закончить диагностику будет некому. Решите, какой маршрут правильный, запишите, как отменить изменение, и только потом выполните его. У проверки нет такого хвоста.

Та же осторожность относится к очистке кэшей и перезапуску сетевых служб как первому шагу, потому что оба уничтожают доказательство, которое вы собирались прочитать. Проверки только для чтения дешевы, повторяемы и безопасны в любом порядке. Сделайте их шагом по умолчанию и беритесь за изменение только тогда, когда доказательство на него указывает.