Маршрутизиране на един 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 към локална заглушка не е доказателство, че горната заявка е използвала маршрута на браузъра, нито успешното зареждане на страница от кеша.

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 все още е наличен, ако отделни интерфейси и отделно състояние са това, което наистина ви трябва.