Маршрутизація одного облікового запису Linux через OpenVPN правилом UID

Маршрутизація за обліковим записом підходить, коли кожен IPv4-сокет одного користувача Linux має виходити через наявний тунель, і не підходить, коли потрібна ізоляція на рівні програми. Вона вибирає за UID, тож усе, що працює під цим записом, потрапляє в обсяг, включно із забутим пакетним завданням. Вирішіть це питання, перш ніж торкатися хоча б одного ip rule.

Приклад нижче припускає окремий обліковий запис браузера з UID 1500, тунельний пристрій tun-office з локальною адресою 10.80.0.11 і VPN, що дозволяє зазначені призначення. Сам демон працює поза цим UID.

Три умови, що вибирають механізм

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

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

Таблиця, правило і запобіжник

Після перевірки наявних правил і вибору невикористаних номерів таблиці та пріоритету схема коротка: маршрут за замовчуванням в окремій таблиці з адресою джерела тунелю, правило, що надсилає запити облікового запису до цієї таблиці, і завершальне правило, що блокує резерв. У записаному вигляді це ідемпотентна заміна маршруту, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, за якою йде ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Запобіжник це ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, і він важливіший, ніж підказує його довжина. Без нього відсутній маршрут у таблиці 51820 провалюється в звичайний аплінк, і обліковий запис тихо випускає трафік, який політика мала перехопити. З ним той самий збій стає тайм-аутом, тобто блокуванням, а не резервом.

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

Що залишає поза увагою маршрутизація за UID: DNS

Демон резолвера відкриває свої висхідні сокети під власним UID, тож вибір 1500 не переносить ці запити до таблиці 51820. Інтеграція DNS це окреме рішення: скеруйте обліковий запис на резолвер, доступний через тунель, або прийміть, що розв'язання імен іде шляхом хоста, а трафік ні.

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

IPv6 потребує власного речення в проєкті

Правила вище охоплюють лише IPv4. Якщо вимога це тунель IPv4 без прямого IPv6 з цього облікового запису, додайте переглянуте завершальне правило, наприклад ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, потім перевірте раніші правила IPv6 і винятки loopback, які хочете зберегти.

Блокування прямого IPv6 це не тунелювання з подвійним стеком; це межа. Якщо назвати це тунелюванням, наступна людина, яка прочитає політику, заплутається, і плутанина випливе як звернення до підтримки про зламаний сайт IPv6.

Перевірте на реальному обліковому записі, а потім візьміть на себе життєвий цикл

Порівняйте запити: ip -4 route get 198.51.100.25 uid 1500 до того ж призначення зі звичайним UID. Потім виконайте дозволений запит під окремим обліковим записом і перевірте адресу джерела, яку бачить віддалена сторона. Бажана адреса джерела це не source NAT, і вона не перекриє програму, прив'язану до чогось іншого. Якщо обидва запити повертають той самий шлях, правило робить не те, що ви думаєте.

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