Таблица за маршрутизиране срещу фактическо търсене: накъде отива трафикът на VPN

Дампът на таблицата за маршрутизиране е най-безполезната диагностика при отстраняване на проблеми с VPN и най-често поставяната. Четиридесет реда с префикси ви казват какво машината би могла да направи, а не какво е направила за неуспешната заявка. Механизмът, който всъщност искате, е търсенето: при този източник и тази дестинация кое правило е съвпаднало, коя таблица е била прегледана и кой интерфейс и следващ хоп са излезли. Започнете от една дестинация и един източник, после четете таблицата с този въпрос в ръка и същият изход става доказателство вместо шум.

Таблицата е набор от кандидати, а не решение

Всеки запис описва префикс и какво да се прави с трафика, който му съответства: да се изпрати към интерфейс, да се предаде на следващ хоп или да се отхвърли. Нищо в този списък не е подредено по намерение и записът, който на човек изглежда най-конкретен, не винаги е този, който ядрото избира, защото изборът следва най-дългото съвпадение на префикс, а при равни префикси — метриката.

Затова първата стъпка е да попитате ядрото, вместо да четете списъка. Командата за търсене отговаря за дестинация, а с аргумент за източник отговаря за точната двойка, която би използвала препратена или свързана връзка:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Всеки адрес по-горе е документационен пример. Смисълът е във формата на отговора: интерфейс, избран адрес на източника, шлюз и таблицата, от която е дошъл записът. Ако този изход не съвпада с интерфейса, който сте очаквали, локализирали сте проблема с една команда и никакво четене на пълната таблица нямаше да ви каже кой кандидат е победил.

Търсенето минава първо през правила, после през таблици

В Linux решението е на два етапа. Правилата на политиката се оценяват по ред на приоритет и първото правило, което съвпадне, посочва таблица за преглед; после тази таблица прави съвпадението по най-дългия префикс. Правилото може да съвпада по източник, дестинация, маркировка на защитната стена, интерфейс или комбинация, поради което дампът на основната таблица може да е напълно точен и напълно неуместен за пакета, който изследвате.

ip rule show
ip route show table all | head -40
ip route show table 100

Ако правило изпраща трафик от вашия VPN пул към таблица 100, то таблица 100 е тази, която има значение, и основната таблица е примамка. Това е и механизмът зад маршрутизирането по източник на рутер: една и съща дестинация може да има два различни отговора в зависимост от това откъде идва пакетът и само търсенето с аргумент за източник показва кой от тях се прилага.

IPv6 има свои правила и таблици. Дизайнът, който работи и с двете семейства, се нуждае от двете търсения, а работещ отговор за IPv4 не казва нищо за пътя v6, който клиент с двоен стек може да предпочете.

Какво инсталира VPN клиентът

Клиентите обикновено не заменят маршрута по подразбиране, защото това би счупило собствения външен път на тунела. Те инсталират нещо по-конкретно, което побеждава по дължина на префикса: двойка половин маршрути по подразбиране, покриващи 0.0.0.0/1 и 128.0.0.0/1, е класическият трик, тъй като и двата са по-дълги префикси от 0.0.0.0/0 и заедно покриват цялото пространство. Други инсталират конкретни частни префикси плюс правило за политика, а някои добавят маркировка, така че да се прихваща само избран трафик.

Затова "VPN не промени маршрута ми по подразбиране" не е доказателство за повреда. Проверете какво все пак е добавил и дали въпросната дестинация попада в тези префикси:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Два половин маршрута лесно се пропускат в дамп, защото не изглеждат като маршрут по подразбиране. Конфигурация на разделен тунел, която е забравила да включи префикс, дава точно симптома, който търсите: приложението, което трябва да използва тунела, вместо това резолвва и се свързва локално. Сравнете инсталираните префикси с дестинациите, които потребителят наистина има нужда, а не с адресите, които случайно сте тествали. Списък на разделен тунел, който покрива файловия сървър, но не неговия резолвер, дава връзка, която се резолвва към публичен адрес и после не успява да се удостовери; това изглежда като проблем с парола, а е проблем с маршрут.

Външният маршрут също трябва да оцелее

Тунелът сам по себе си е трафик. Пакетите, които носят инкапсулирания товар, отиват до адреса на партньора през физическия интерфейс и този път не бива да се маршрутизира обратно в тунела. Когато това стане, получавате характерния отказ, при който тунелът се установява и после спира да пропуска трафик, защото транспортът за тунела вече е вътре в тунела.

Проверете адреса на партньора по същия начин, по който проверихте вътрешната дестинация, и потвърдете, че той се резолвва към физическия интерфейс, а не към тунела:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Рекурсивен маршрут, правило за политика, което прихваща партньора, или маршрут по подразбиране, заменен от клиент на пълен тунел, са трите обичайни причини. И трите се виждат във външното търсене и нито една от тях не се вижда в дамп на основната таблица, направен след факта.

Какво не може да ви каже изходът от маршрутизирането

Правилното търсене означава, че ядрото би изпратило пакета на разумно място. То не означава, че защитната стена го разрешава, че политиката на IPsec го покрива, че правилото на NAT го преобразува или че отдалечената страна има обратен маршрут. Всяко от тях е по-късен етап и бележките на strongSwan за препращане описват веригата, която пакетът трябва да премине в двата края.

То също не отчита обвързването на ниво приложение. Процес може да се обвърже с интерфейс, да зададе маркировка или да използва свой резолвер и да се свърже с име, което се резолвва различно от това, което сте тествали. Когато търсенето е правилно, а връзката все още се проваля, следващият въпрос е кой процес я осъществява и дали този процес вижда същата таблица като вас.

Затова поддържайте диагнозата подредена: назовете дестинацията и източника, изпълнете търсенето, прочетете само таблицата и правилото, които търсенето е посочило, после тествайте следващия етап. Тази последователност държи разследването на маршрутизирането в рамките на минути и оставя запис, който друг може да проследи, каквото поставена таблица никога не прави.