Защо 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 е включен, честният отговор обикновено е конкретен маршрут до хоста през локалния рутер, инсталиран от мрежовия мениджър, който притежава интерфейса. Ако изискването е да достигате всичко директно, самото изискване се нуждае от преглед на политиката, преди да се нуждае от команда за маршрут.