Какви способности на Linux са нужни на VPN процеса ви?
Настройката на интерфейса, маршрутите, достъпът до устройства и обикновените сокети са отделни привилегии. Назовете операцията, която се провали, преди да дадете CAP_NET_ADMIN.
Демонът на VPN се нуждае от привилегировани мрежови операции, макар обикновените програми да отварят изходящи сокети без никакви привилегии. Именно в тази разлика започват повечето грешки със способностите: някой вижда грешка за права, дава целия набор и услугата работи по причини, които по-късно никой не може да обясни. Разглеждането по-долу започва от неуспешната операция, свързва я с едно правомощие и след това проверява контекста, в който процесът реално работи. Работата като неограничен root е валиден отговор за някои внедрявания, но трябва да бъде решение, а не настройка по подразбиране.
Започнете от операцията, която се провали
Прочетете грешката, преди да четете ръководство. „Операцията не е разрешена“ при промяна на интерфейс, отказ да се отвори възел на устройство и неуспешно свързване към нисък порт са три различни проблема с три различни разрешения. Ако процесът стартира и се проваля само при първата промяна на маршрут, това също показва, че създаването на интерфейса вече е успяло, което значително стеснява отговора.
Възпроизведете проблема със спряна услуга, след което я стартирайте на преден план под същия потребител, ако реализацията го позволява. Грешка, която виждате, е по-добра от ред в журнала, който трябва да гадаете, и прави очевидна разликата между проблем със способности и отказ от SELinux или AppArmor.
Свържете всяка операция с едно правомощие
Таблицата е начална карта, а не заместител на документацията на реализацията:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
Двата реда в тази таблица са тези, които хората бъркат. Отварянето на /dev/net/tun е въпрос на файлови права; искането към ядрото да конфигурира това, което сте отворили, е въпрос на способности. Даването на CAP_NET_ADMIN не поправя възел на устройство, който потребителят на услугата ви не може да прочете, а поправянето на възела не ви дава правомощия за маршрути. Проверете и двете, преди да промените което и да е от тях.
WireGuard в ядрото и тунелните програми в потребителско пространство също нямат еднакви изисквания. Пътят през модула в ядрото конфигурира съществуващ интерфейс чрез netlink, докато реализация в потребителско пространство може да се нуждае и от устройството, а за някои транспорти — и от сурови сокети.
Прочетете контекста: услуга, контейнер или обвивка
Способност в мрежовото пространство от имена на хоста може да повлияе много повече от същата операция в умишлено изолиран стек. Среда за контейнери обикновено стартира с намален набор от граници; добавянето на NET_ADMIN към контейнер, който споделя мрежата на хоста, е много по-голямо разрешение от добавянето му към контейнер със собствено мрежово пространство от имена и без монтирания от хоста.
За unit-и на systemd четете какво реално се прилага, а не какво изглежда, че казва файлът на unit-а: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities отчита ефективните стойности, които може да са зададени от drop-in, който сте забравили. Питайте за ефективната стойност, никога за предвидената. Ambient способностите имат значение, защото услуга без root губи способностите си през exec без тях.
Използвайте поддържаната настройка на пакета или образа като основа. Не добавяйте разрешения за сурови сокети или привилегирован режим, защото друг урок ги е изброил за друг инструмент; тази логика не пренася нищо и ви струва изолацията, за която сте платили. При съмнение не давайте нищо и прочетете бележките на реализацията за точната операция, която ви трябва.
Наблюдавайте какво се случва след спадане на привилегиите
Много демони стартират с привилегии, конфигурират интерфейса, след което преминават към непривилегирован потребител и запазват тунела. От този момент процесът вече не може да добави маршрут, да пренапише правило на защитна стена или да отвори ново привилегировано устройство, което е нормално, докато повторното свързване не поиска точно това. По-късните четения на файлове и изпълнение на куки може да се провалят по същата причина.
Тествайте целия жизнен цикъл, а не първата секунда: стартиране, подновяване или повторно свързване и почистване при спиране. Първото успешно създаване на интерфейс не доказва, че всяка следваща привилегирована операция ще работи, а проблемът обикновено се появява часове по-късно в продукция.
Реализациите, които държат тунела отворен при смяна на потребител, обикновено съчетават това с опции за запазване на тунела и ключовете. От страна на systemd еквивалентният въпрос е дали наборът от способности на unit-а оцелява при смяната на потребителя, която сте настроили.
Запишете разрешението и причината за него
Запишете точното разрешение, операцията, която то позволява, и грешката, която е отстранило. Един ред в бележките за внедряване — „CAP_NET_ADMIN в мрежовото пространство от имена на unit-а, нужен за промени в маршрутите след повторно свързване“ — е достатъчен, за да спре следващия човек да разшири разрешението отново.
След това препрочетете ефективния набор след всяка актуализация. Доставчиците добавят функции, образите променят настройките по подразбиране и способност, която миналата година е била ненужна, може да стане носеща, без никой да забележи.