Разделяне на тунела по приложение и по дестинация: кое да изберете

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

Двете правила действат на различни слоеве

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

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

Правилата за приложения пасват на мобилни клиенти и управлявани агенти

Android показва избора директно: VpnService.Builder.addAllowedApplication() и addDisallowedApplication() приемат имена на пакети и налагат решението за всеки UID, както е описано в ръководството за разработчици на VPN в Android. iOS има еквивалент чрез VPN правила за отделно приложение, обвързани с идентификатори на пакети, обикновено доставяни чрез MDM профил, а не набирани на ръка.

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

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

Правилата за дестинация пасват на списъци с подмрежи и достъпност на сайтове

WireGuard прави модела явен. AllowedIPs е маршрутизация по криптоключ: вътрешен пакет, чиято дестинация попада в списъка на партньор, се шифрова към него, а всичко останало излиза нешифровано по нормалния път. Няма процес за именуване и няма двусмислие какво е включено.

OpenVPN стига до същото чрез изтласканата таблица за маршрути. route-nopull спира сървъра да диктува маршрути, след което клиентското route 10.20.0.0 255.255.0.0 vpn_gateway покрива точно офис префикса. IPv6 е отделен израз във всеки от тези клиенти и забравянето му е най-честият начин за изтичане около правилно изглеждащо разделяне на IPv4.

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

Къде се чупят и двата модела: помощни процеси, споделени услуги, резолвери

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

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

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

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

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

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

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Първите два реда назовават интерфейса, който реална дестинация би използвала; wg show отпечатва конфигурирания списък с префикси; в Windows Find-NetRoute отговаря на същия въпрос, на който стекът ще отговори при изпращане на пакета. Ако интерфейсът е тунелът, правилото е съвпаднало.

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