Проверка на 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, който администрирате отдалечено, едно небрежно редактиране на таблицата може да отнеме самия път обратно до машината и никой да не може да завърши диагностиката. Решете кой е правилният маршрут, запишете как да отмените промяната и само след това я изпълнете. Инспекцията няма такава опашка.

Същото внимание важи за изчистването на кешове и рестартирането на мрежови услуги като първа стъпка, защото и двете унищожават доказателството, което щеше да прочетете. Проверките само за четене са евтини, повторяеми и безопасни в произволен ред. Направете ги стъпка по подразбиране и посегнете към промяна само когато доказателството сочи към нея.