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

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

Три различни свързвания, три различни последици

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

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

Определете какво всъщност задава приложението

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

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

Маршрутизацията по политика чете източника

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

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

Разделен тунел и помощни процеси

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

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

Тествайте собствения път на приложението

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

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