Чому 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 увімкнено, чесна відповідь зазвичай конкретний маршрут до хоста через локальний маршрутизатор, установлений мережевим менеджером, якому належить інтерфейс. Якщо вимога — досягати будь-чого напряму, сама вимога потребує перегляду політики раніше, ніж команди маршруту.