Перевірка маршруту VPN у macOS: route get без жодних змін
Знімок екрана маршруту за замовчуванням може пропустити конкретніший шлях. Запитайте невдалий пункт призначення за допомогою 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, яким ви керуєте віддалено, одна недбала правка таблиці може забрати саме шлях назад до машини, і завершити діагностику не буде кому. Вирішіть, який маршрут правильний, запишіть, як скасувати зміну, і лише тоді виконайте її. У перевірки немає такого хвоста.
Та сама обережність стосується очищення кешів і перезапуску мережевих служб як першого кроку, бо обидва знищують доказ, який ви збиралися прочитати. Перевірки лише для читання дешеві, повторювані й безпечні в будь-якому порядку. Зробіть їх кроком за замовчуванням і беріться до зміни лише тоді, коли доказ на неї вказує.