Рекурсивно маршрутизиране: когато тунелът прихване собствените си пакети

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

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

Проверете първо външния път

В играта има два пакета, не един. Вътрешният пакет принадлежи на приложението и трябва да бъде шифрован, докато външният пакет е адресиран до сървъра и трябва да го достигне по път, който не зависи от тунела.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

Защо сесията оцелява за миг

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

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

Открийте кой притежава изключението за крайната точка

Поддържаните клиенти уреждат сами своето изключение: маршрут до хоста на сървъра през първоначалния шлюз или маркировка, която държи външния сокет извън тунела. Въпросът е дали нещо друго не го е премахнало или заменило.

За IPsec, базиран на маршрути, прегледайте селекторите на политиката, които решават кои пакети влизат в тунела, и потвърдете, че адресът на партньора е изключен от тях. За WireGuard маркировката на защитната стена на интерфейса и правилата му за политика държат транспортните пакети извън тунела, така че ръчно добавен маршрут по подразбиране може да развали тази подредба. Втори профил VPN или административен скрипт, който пренаписва маршрута по подразбиране, е чест виновник. Широки правила за заобикаляне, добавени едно по едно, са обичайният резултат и те превръщат грешка в маршрутизирането в таблица, която никой не може да поддържа.

Проверете отново след промяна на мрежата

Маршрут до хоста през Wi-Fi шлюз е правилен, докато машината не премине в друга мрежа. Тогава същият симптом се връща без никаква промяна в конфигурацията.

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

Свържете се отново в новата мрежа и повторете четенето. Ако изключението отново липсва, поправката принадлежи на профила, който го притежава, а не на еднократна команда, написана по време на прекъсване.

Подобни статии