Tavaline Linuxi rakendus kasutab VPN-i ilma TUN-i puutumata

Juba loodud Linuxi VPN-i kasutav brauser ei ava /dev/net/tun. See avab sokli ja tuum otsustab, millise liidese kaudu selle sokli paketid väljuvad. Tunnelit loonud protsess teeb teistsugust tööd kui protsess, mille liiklust see kannab. Nende kahe rolli lahus hoidmine vastab enamikule õiguste küsimustele enne, kui need küsitakse.

Jälgi üht paketti soklist tunnelini

Tavaline rakendus kutsub connect või send ja tuum otsib sihtkoha marsruudi. Kui valitud marsruut osutab tunneli liidesele, pannakse pakett järjekorda seadmesse, mida VPN-i deemon loeb. Deemon krüpteerib selle ja saadab välja füüsilise liidese kaudu. Iga nool selles kirjelduses on koht, kus saab õiguste küsimusele vastata.

Miski selles teekonnas ei nõua, et rakendus seadmest teaks. Deemon hoiab failikirjeldajat ja teeb liidese toiminguid, samal ajal kui rakendus näeb ainult tavalist võrgu-API-t.

Joonista kaks poolt korra ja õiguste küsimusi on lihtsam paigutada. Ülemine pool on rakenduste maailm ja alumine kuulub deemonile.

Otsusta, kes seadet vajab ja kes mitte

TUN-liidese loomine või sellega liitumine nõuab seadmele juurdepääsu ja lisaks õigust seda seadistada, mistõttu toetatud VPN-teenus algab võrguadministraatori volitusega või kasutab privilegeeritud abiprogrammi. See nõue kuulub deemonile. See ei ütle midagi brauseri, andmebaasikliendi ega failiedastustööriista kohta. Teenus, mis seda õigust vajab, vajab seda oma seadistusetapi jaoks, mitte klientide jaoks.

Kui marsruut ja poliitika on paigas, kasutab tavaline protsess saadud teed oma tavaliste soklikutsete kaudu. Ta ei vaja seadme sõlme ega root-i.

Seadme õiguste muutmine ei ole viis, kuidas anda rakendusele sihtkoha juurdepääs. See ainult liigutab seadme piiri mujale.

Kontrolli nimeruumi, kus rakendus tegelikult töötab

Konteiner või teine võrgu nimeruum annab oma protsessidele eraldi liideste komplekti ja marsruutimistabeli. Hostis asuv tunnel ei ilmu sinna automaatselt ja ükski seadme õiguste muudatus ei muuda seda. Rakendus marsruudib lihtsalt selle kaudu, mida see nimeruum pakub. Seetõttu ei saa konteineripilt kogemata hosti tunnelit pärida.

Kontrolli käsuga ip netns list ja ip -n NAME route või vaadates protsessi nimeruumi linki. Vastus on tavaliselt ühe käsuga nähtav.

Samal hostil saab kahele kasutajale anda poliitikaga erinevad teed. See on võrguotsus, mitte tõend seadme omandi kohta.

Eralda õigused võrgupoliitikast

Mõned tööriistad vajavad enamat kui soklit. Pakettide püüdmine vajab toorsoklit ja marsruutide muutmine nõuab administraatori volitust. Need on eraldi toimingud eraldi lubadega ja ühe andmist ei tohiks lugeda üldiseks VPN-i kasutamise nõudeks.

Programm, mis rakendab oma tunnelit, on kolmas juhtum. See avab TUN-i tõesti, sest võtab deemoni rolli, mistõttu vajab deemoni privileege.

Nimeta toiming enne privileegi nimetamist. Neid kahte on tavaliselt lihtsam eraldada, kui tundub.

Kontrolli jaotust kahe kontoga

Ühenda tunnel teenusena, seejärel käivita rakendus tavalise kasutajana ja kinnita, et see jõuab privaatse ressursini. Kontrolli ip route get sihtkoha jaoks selle kasutaja shellist, et näha, milline liides valiti. Kui marsruut on õige ja ühendus siiski ebaõnnestub, on probleem poliitikas, mitte privileegis.

Tulemuseks on vähimate õigustega disain selge piiriga: üks komponent omab seadistust ja tunneli ressursse, töökoormused säilitavad oma tavalised kontod ja võrgupoliitika otsustab, mis võib läbi pääseda. Kõige käitamine root-ina surub need rollid kokku, selgitamata midagi.