Обична Linux апликација користи VPN без да го допре TUN

Прелистувач што користи веќе воспоставен Linux VPN не го отвора /dev/net/tun. Отвора сокет, а јадрото одлучува низ кој интерфејс излегуваат пакетите на тој сокет. Процесот што го создал тунелот работи друга работа од процесот чиј сообраќај го пренесува. Одвојувањето на овие две улоги одговара на повеќето прашања за дозволи пред тие да бидат поставени.

Следи еден пакет од сокетот до тунелот

Обична апликација повикува connect или send, а јадрото бара маршрута до целта. Ако избраната маршрута покажува кон интерфејсот на тунелот, пакетот се става во редот кај уредот што го чита демонот на VPN. Демонот го шифрира и го испраќа низ физичкиот интерфејс. Секоја стрелка во тој опис е место каде што може да се одговори на прашање за дозвола.

Ништо на тој пат не бара апликацијата да го познава уредот. Демонот го држи описот на датотеката и ги извршува интерфејсните операции, додека апликацијата гледа само нормален мрежен API.

Нацртајте ги двете половини еднаш, и прашањата за дозволи ќе бидат полесни за сместување. Горната половина е светот на апликациите, а долната му припаѓа на демонот.

Одлучете кому му е потребен уредот, а кому не

Создавањето или приклучувањето кон интерфејс TUN бара пристап до уредот и дополнително способноста да се конфигурира, затоа поддржаната VPN услуга започнува со овластување за мрежна администрација или користи привилегиран помошник. Тоа барање му припаѓа на демонот. Не кажува ништо за прелистувачот, клиентот на базата на податоци или алатката за пренос на датотеки. Услугата што ја бара способноста ја бара за сопствениот чекор на поставување, не за своите клиенти.

Откако маршрутата и политиката се на место, обичен процес го користи добиениот пат преку своите вообичаени сокет повици. Не му треба јазолот на уредот, и не му треба root.

Менувањето на дозволите на уредот не е начин да се даде пристап на апликацијата до целта. Тоа само ја преместува границата на уредот на друго место.

Проверете во кој именски простор всушност работи апликацијата

Контејнер, или втор мрежен именски простор, на своите процеси им дава одделен сет интерфејси и табела на маршрути. Тунел на домаќинот не се појавува таму автоматски, и ниту една промена на дозволите на уредот тоа не го менува. Апликацијата едноставно ќе насочува низ она што го обезбедува тој именски простор. Затоа контејнерска слика не може случајно да наследи тунел од домаќинот.

Проверете со ip netns list и ip -n NAME route, или со преглед на врската на именскиот простор на процесот. Одговорот обично се гледа со една команда.

На двајца корисници на истиот домаќин може да им се дадат различни патишта со политика. Тоа е мрежна одлука, а не доказ за сопственост на уредот.

Одвојте ги способностите од мрежната политика

Некои алатки бараат повеќе од сокет. Фаќањето пакети бара суров сокет, а менувањето маршрути бара административно овластување. Тоа се одделни операции со одделни дозволи, и давањето на една не треба да се чита како општо барање за користење на VPN.

Програма што имплементира сопствен тунел е трет случај. Таа навистина го отвора TUN затоа што ја презема улогата на демонот, поради што ги бара неговите привилегии.

Именувајте ја операцијата пред да ја именувате привилегијата. Двете обично се разделуваат полесно отколку што изгледа.

Проверете ја поделбата со две сметки

Поврзете го тунелот како услуга, потоа стартувајте ја апликацијата како обичен корисник и потврдете дека стигнува до приватниот ресурс. Проверете ip route get за целта од shell-от на тој корисник за да видите кој интерфејс е избран. Ако маршрутата е точна, а врската продолжува да не успева, проблемот е политиката, а не привилегијата.

Добиениот дизајн е минимална привилегија со јасна граница: една компонента го поседува поставувањето и ресурсите на тунелот, работните оптоварувања ги задржуваат нормалните сметки, а мрежната политика одлучува што може да помине. Извршувањето на сето како root ги урива тие улоги без ништо да објасни.