Могат ли DHCP маршрутите да изведат трафика ви извън VPN тунела?

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

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

Два начина, по които една мрежа може да ви повлияе

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

Оборудването по пътя не се нуждае от ключовете ви, за да влияе на втория случай. То се нуждае само крайната ви точка да приеме маршрут, резолвер или правило за политика, което създава такъв.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

Откъде може да дойде маршрут, преди тунелът да съществува

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

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

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

Проверете пътя, който ядрото действително избира

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

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

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

Не спирайте на маршрута по подразбиране. Изключение за приложение, префикс на разделен тунел или второ правило за политика могат да пренесат конкретно местоназначение покрай тунела, докато маршрутът по подразбиране все още сочи вътре.

Решете къде трябва да живее налагането

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

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

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