Застосунок прив’язано до інтерфейсу? Його шлях через VPN не типовий

Один застосунок на машині виходить через VPN, інший — ні, і обидва користувачі присягаються, що нічого не змінювали. Різниця часто в рішенні про прив’язку, яке ухвалює сам застосунок: сокет, прив’язаний до пристрою, вихідна адреса, вибрана до з’єднання, або простір імен із власною таблицею маршрутизації. Кожне з них змінює те, який шлях діє, і жодне не видно у звичайній перевірці IP у браузері.

Три різні прив’язки, три різні ефекти

Прив’язка до пристрою й прив’язка до вихідної адреси — споріднені операції з різними наслідками. Прив’язка до пристрою може змусити трафік вийти через один інтерфейс і обійти звичайний пошук маршруту для цього сокета. Прив’язка до вихідної адреси все одно проходить через вибір маршруту, але вибране джерело може збігтися з правилом політики й відправити пакет в інше місце. Різниця звучить академічно, доки правило не почне маршрутизувати за джерелом. Тоді воно вирішує все.

Мережевий простір імен — третій випадок. У нього свої інтерфейси й своя таблиця маршрутизації, тому застосунок усередині нього взагалі не зазнає впливу типового значення хоста. Якщо вважати всі три одним і тим самим, виходять самовпевнені пояснення, які не витримують першої перевірки.

Визначте, що застосунок насправді задає

Прочитайте мережеву конфігурацію застосунку або його задокументовану поведінку, перш ніж чіпати маршрути. Якщо він пропонує вибір інтерфейсу, поле вихідної адреси або параметр простору імен, саме цей параметр треба перевірити першим. Якщо ні, прив’язка може бути внутрішньою і видимою лише через трасування або власну діагностику.

У Linux параметри сокета на кшталт SO_BINDTODEVICE мають задокументований обсяг і вимоги до прав, і непривілейований процес може взагалі не змогти їх задати. Це обмеження — корисна підказка: якщо параметр не можна застосувати, застосунок, імовірно, не є джерелом різниці.

Маршрутизація за політикою читає джерело

Коли налаштовано маршрутизацію за політикою, правило може вибрати таблицю на основі джерела пакета. Тож сокет, що прив’язує вихідну адресу, може йти за правилом, якого типовий шлях ніколи не торкається, навіть якщо жоден інтерфейс не названо явно.

Відтворіть пошук із тим самим сімейством адрес, джерелом і простором імен, які використовує застосунок. Звичайний пошук маршруту з оболонки в просторі імен хоста відповідає на інше питання, і саме ця невідповідність — найчастіша причина того, що робочий маршрут виглядає зламаним.

Розділений тунель і допоміжні процеси

Розділений тунель для окремих застосунків додає ще один шар. Клієнт може зіставляти пакет або процес застосунку, а помічник, який відкриває власний сокет, — окремий суб’єкт. Запускач і його фонова служба можуть створювати різні з’єднання під одним видимим ім’ям.

Перевірте, чи правило розділеного тунелю охоплює процес, який справді підключається. Якщо застосунок прив’язаний до певного інтерфейсу, а клієнт VPN зіставляє за пакетом, два рішення можуть розходитися, і жодне не буде помилковим.

Перевірте власний шлях застосунку

Запускайте новий запит із застосунку після кожної зміни. Браузер, що показує потрібний вам вихід, не є рівноцінним доказом для іншої програми, прив’язаної до іншого інтерфейсу, а кешовані з’єднання можуть ще довго використовувати старий шлях після зміни налаштування. Закрийте стару сесію, перш ніж оцінювати нове правило. Інакше перевірка вимірює минуле.

Довідник із сокетів Linux описує SO_BINDTODEVICE та його вимоги. Спершу прочитайте власну конфігурацію застосунку, відтворіть пошук у тому самому контексті й лише потім вирішуйте, чи треба змінювати маршрут або прив’язку.