Защо маршрут на VPN не показва шлюз в резултата от ip route
Ред с устройство и без шлюз е директен маршрут, а не счупен. Разчетете дестинацията, dev и scope, после потвърдете с ip route get.
Таблиците за маршрутизиране биват разчитани като счупени, когато колоната за шлюз остане празна, макар редът обикновено да е завършен сам по себе си. Полето via се появява само когато ядрото предаде пакета на адрес за следващ хоп; маршрут, прикачен към интерфейс, достига дестинациите си чрез разделяне на каналния слой или чрез партньор точка-точка. Разчитането на колоните отляво надясно показва в кой случай се намирате и това разчитане трябва да стане, преди някой да редактира маршрут по подразбиране. Повечето заявки за липсващ шлюз приключват точно при това разграничение.
Разчитайте ред от маршрутната таблица колона по колона
Всеки запис започва с дестинацията и дължината на префикса ѝ, после добавя модификатори в фиксиран речник: via, dev, proto, scope, src и metric. Ред като 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 е плътен, но напълно зададен. В него не липсва нищо и не се подразбира никакъв адрес на рутер.
Липсата на via е интересната част. Без следващ хоп ядрото разделя дестинацията директно на посочения интерфейс, което за тунел означава предаване на кадъра на тунелното устройство и оставяне на инкапсулацията да го поеме оттам. proto kernel отбелязва, че записът е инсталиран автоматично при задаване на адрес, а не е въведен от администратор. scope link казва, че дестинацията е достижима по тази връзка без преминаване през рутер, а src посочва адреса, който ядрото ще предпочете като източник за съответстващия трафик.
Сега разчетете маршрут по подразбиране по същия начин: default via 192.0.2.254 dev eth0 proto static metric 100. Тук via присъства, защото пакетът наистина се нуждае от следващ хоп и този хоп сам трябва да е достижим на eth0. Двата реда не са варианти един на друг; те отговарят на различни въпроси за това накъде отива трафикът.
Две форми на маршрут, които се бъркат една с друга
Маршрут към подмрежа на тунел и маршрут по подразбиране изглеждат подобни на снимка на екрана и се държат съвсем различно. Използвайте таблицата по-долу като помощ за разчитане на полетата, после потвърдете действителните числа на машината, която отстранявате, вместо да се доверявате на пример от ръководство.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Това, което таблицата не може да ви каже, е намерението. Директен маршрут към частен диапазон през тунел е умишлен дизайн на разделено тунелиране; същата форма на хост, който трябва да изпраща всичко през VPN, е симптом. Намерението живее в конфигурацията, създала записа, затова погледнете инструмента, който го е инсталирал, преди да заключите, че ядрото е сбъркало нещо.
По същия начин липсващият шлюз не е разрешение да си измислите такъв. Ако маршрутът наистина се нуждае от следващ хоп, този хоп трябва да е достижим на интерфейса, който го носи, а за тунел точка-точка адресът на партньора не е същият обект като локалния адрес. Третирането на локалния тунелен адрес като Ethernet рутер е чест начин да се получи маршрут, който изглежда правилен и не препраща нищо.
Питайте ядрото кой ред действително ще използва
Разчитането на таблицата не е същото като извършването на търсенето, защото ядрото се консултира с правила за политика, няколко таблици и кеширани записи, преди да отговори. Глаголът, който извършва истинското търсене, е ip route get, и той отпечатва маршрута, който пакет с тези свойства би поел.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Заменете с дестинацията, която наистина ви интересува, после добавете from или iif, когато трафикът е избран по източник или се препраща, защото обикновеното локално търсене може да избере различен път от препратения клиент. Отговорът посочва интерфейса, избрания адрес на източника и всеки следващ хоп, което е същата информация, с която пакетът би бил маршрутизиран в онзи момент.
Ако отговорът ви изненада, отпечатайте правилата преди каквато и да е промяна: ip -4 rule show ги изрежда по ред на приоритет, а клиент на VPN, който инсталира собствена таблица или правило за маркирани пакети, изобщо няма да се появи в основната таблица. Изреждането на всички таблици затваря тази празнина.
ip -4 route show table all | grep -E 'tun|default'Проверете подложката, преди да замените маршрута по подразбиране
Собствените пакети на тунела трябва да достигнат до отдалечената крайна точка и го правят през физическия интерфейс, използвайки маршрута, който е съществувал преди включването на VPN. Замяната на целия маршрут по подразбиране без закрепване на тази крайна точка изпраща инкапсулираните пакети в тунела, който те трябва да построят, и връзката се срива. Първо потвърдете пътя до крайната точка с търсене само по адреса ѝ.
Дръжте три неща разделени, когато правите промяната: маршрута до крайната точка, който трябва да остане на физическия интерфейс, частните диапазони, които трябва да влязат в тунела, и маршрута по подразбиране, който решава всичко останало. Разделете ги в този ред, прилагайте по един наведнъж и пускайте търсенето отново след всяка стъпка. Неуспешен ping след това сам по себе си доказва много малко, тъй като разрешенията, маршрутизирането на отговорите, DNS и самата услуга стоят надолу по веригата от правилния маршрут.
Запишете четирите стойности, които редът ви даде преди редакцията: дестинация, следващ хоп или неговата липса, устройство и избран източник. Ако по-късна промяна премести някое от тях, знаете кое решение всъщност е било променено и можете да възстановите един запис, вместо да гадаете за цялата таблица.