Защо една подмрежа все още заобикаля маршрута по подразбиране на VPN

Превключвате VPN към пълен тунел, повечето трафик се подчинява, а после един адрес отговаря директно — принтер, NAS, междинен хост на 10.x. Очевидното обяснение е, че тунелът изтича, затова намалявате метриката на маршрута по подразбиране и нищо не се променя. Този неуспешен опит е уликата: маршрутът по подразбиране е резерва, а не присъда. Търсенето на маршрут взима най-дългия съвпадащ префикс, преди изобщо да сравни метрики, така че /24 продължава да печели срещу /0, каквото и число да прикачите към който и да е от тях. Щом този ред е ясен, „изтичането“ обикновено е маршрут, който някой е инсталирал нарочно, или префикс, който клиентът никога не е възнамерявал да покрива.

Какво всъщност обещава маршрутът по подразбиране

0.0.0.0/0 съвпада с всяка IPv4 дестинация с нула бита специфичност. Съществува, за да може хостът да достигне всичко, което таблицата му не описва по-добре. Маршрут към 192.168.1.0/24 носи 24 съвпадащи бита, така че за 192.168.1.40 печели, преди някой да сравни метрики, административно разстояние или каквото клиентът нарича поле за приоритет. Същото правило важи в Linux FIB, таблицата за маршрутизация на Windows и BSD стека зад macOS.

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

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

Най-чистият пример е redirect-gateway def1 в OpenVPN. Вместо да изтрие маршрута ви по подразбиране и да го замени, той добавя 0.0.0.0/1 и 128.0.0.0/1. Заедно двойката покрива целия IPv4, всеки префикс е по-дълъг от /0 и двете побеждават маршрута на рутера по подразбиране, като го оставят на място. Пуснете списък на маршрутите след това и оригиналният маршрут по подразбиране все още е там, все още сочи към шлюза ви; просто никога не се избира за интернет дестинации.

wg-quick на WireGuard постига същия резултат чрез маршрутизация по политика. Когато AllowedIPs покрива 0.0.0.0/0, той създава собствена таблица, изпраща маркираните пакети там и добавя правило, което игнорира префикса с нулева дължина на основната таблица. Основната таблица запазва записа си по подразбиране, а правилата решават, че за трафика, който интерфейсът притежава, първо се пита таблицата на тунела.

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

Метриките решават равенства, префиксите решават победители

Метриките се сравняват само между кандидати, които съвпадат с дестинацията еднакво добре. В Linux, ip route get 10.20.5.9 отпечатва победителя заедно с таблицата му, а ip route show table all изброява кандидатите, включително всякакви половин маршрути по подразбиране и всяка таблица, към която сочи правило. В Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 връща избрания маршрут и адрес на източника, докато Get-NetRoute показва суровата таблица — но ефективната цена е метрика на маршрута плюс метрика на интерфейса, така че бавен адаптер може да загуби равенство, което изглежда, че печели.

Три случая покриват повечето от това, което ще видите:

• Една и съща дестинация, /24 срещу /0: /24 печели по дължина на префикса, каквото и да казват метриките.
• Една и съща дестинация, два /24 с различни метрики: по-ниската ефективна метрика печели.
• Една и съща дестинация, две таблици, една избрана от правило за политика: правилото първо избира таблицата и сравнението на префикси става вътре в нея.

Третият случай е мястото, където завършват повечето от тези доклади. Правило ip rule в Linux или филтър за VPN трафик в Windows може да изпрати трафика към таблица, която никога не е държала маршрута по подразбиране на тунела, а основната таблица изглежда безупречна през цялото време.

Кой обикновено притежава заобикалянето

Започнете с профила, не с таблицата. Конфигурациите на split-tunnel и настройките на VPN за отделни приложения умишлено оставят именувани префикси извън тунела; работен профил, който защитава една частна подмрежа и оставя общото сърфиране да минава директно, се държи както е проектиран, а преодоляването му нарушава политиката, която е трябвало да налага. Ръководството за маршрутизация на VPN на Microsoft поставя същата граница между принудително тунелирания трафик и изричните изключения, което го прави полезна кръстосана проверка, преди да редактирате каквото и да е.

След това потърсете остатъци. Маршрут, сочещ към интерфейс, който вече не съществува, или към адрес от предишната мрежа, се появява след идването и отиването на докинг станции, USB адаптери и мостове за контейнери. Изтриването му веднъж не е краят: профилите за връзка на NetworkManager, файловете netplan и постоянните маршрути на Windows го преинсталират при следващото свързване или зареждане, затова намерете файла или профила, който го притежава, преди да редактирате каквото и да е.

После проверете IPv6 отделно. ip -6 route и Get-NetRoute -AddressFamily IPv6 държат отделно състояние, отделни маршрути по подразбиране и отделно поведение на клиента. Одит само на IPv4 не казва нищо за хост с двоен стек, който тихо предпочита роден IPv6 път, и само това може да накара клиента да изглежда в режим split-tunnel.

Потвърдете с реалния поток на приложението

Запишете дестинацията, която приложението действително използва, после попитайте системата за пътя, който би поела от адреса на източника, който това приложение обвързва. ip route get 10.20.5.9 from 192.168.1.40 отговаря на това в Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 плюс локалния адрес прави това в Windows. Сравнете резултата с това, което твърди профилът. Страницата с публичен IP в браузъра тества една дестинация по един протокол и не казва нищо за частния адрес, от който е започнала оплакването.

Поправете най-тесния обект, който обяснява разликата. Ако изключението е одобрено, запишете префикса и го оставете; ако не е, премахнете маршрута или добавете изричен по-тесен маршрут през тунела, вместо да намалявате метриката по подразбиране. Намаляването на метрика не може да надмине по-дълъг префикс, а редактирането на маршрута по подразбиране, докато два маршрута /1 притежават интернет пътя, също не променя нищо.

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

• Назовете дестинацията и адреса на източника, които приложението наистина използва.
• Покажете печелившия маршрут с ip route get или Find-NetRoute.
• Проверете дали двойка /1 или таблица за политика притежава интернет пътя.
• Избройте всеки префикс, по-дълъг от /0, който съвпада с дестинацията.
• Повторете проверката на IPv6 отделно.
• Проследете останалия маршрут до файла, профила или филтъра, който го инсталира.
• Свържете отново и изпълнете отново заявката, преди да го наречете поправено.

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