Как разделеният тунел решава кой трафик използва VPN

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

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

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

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

Ето защо разделеният тунел може да изглежда произволен. Две дестинации в едно приложение могат да поемат различни пътища просто защото единият префикс е по-тесен от другия.

Същият избор съществува на всяка платформа, макар имената да се менят. Windows избутва решението в своята филтърна платформа, Android показва списък с разрешения за всяко приложение чрез своята VPN услуга, а macOS прикачва тунела към устройство, което все още се подчинява на маршрутната таблица. Бележките на Microsoft за маршрутизацията си струват четенето за случая с Windows, а ръководство, написано за една платформа, рядко се пренася непроменено към друга.

Обвързване към приложение и префикси на дестинация са различни инструменти

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

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

DNS и аварийният прекъсвач следват собствени правила

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

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

Проверете разделянето от двете страни

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

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

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

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