Įprasta Linux programa naudoja VPN neliesdama TUN

Naršyklė, naudojanti jau sukurtą Linux VPN, neatidaro /dev/net/tun. Ji atidaro lizdą, o branduolys nusprendžia, per kurią sąsają išeina to lizdo paketai. Tunelį sukūręs procesas atlieka kitą darbą nei procesas, kurio srautą jis perduoda. Šių dviejų vaidmenų atskyrimas atsako į daugumą leidimų klausimų, kol jie dar neužduoti.

Sek vieną paketą nuo lizdo iki tunelio

Įprasta programa iškviečia connect arba send, o branduolys ieško maršruto iki paskirties. Jei pasirinktas maršrutas rodo į tunelio sąsają, paketas įrašomas į eilę įrenginyje, kurį skaito VPN daimonas. Daimonas jį užšifruoja ir išsiunčia per fizinę sąsają. Kiekviena to aprašymo rodyklė yra vieta, kurioje galima atsakyti į leidimo klausimą.

Niekas tame kelyje nereikalauja, kad programa žinotų įrenginį. Daimonas laiko failo deskriptorių ir atlieka sąsajos operacijas, o programa mato tik įprastą tinklo API.

Nubrėžkite abi puses kartą, ir leidimų klausimus bus lengviau išdėstyti. Viršutinė pusė yra programų pasaulis, o apatinė priklauso daimonui.

Nuspręskite, kam reikia įrenginio, o kam ne

Sukurti TUN sąsają arba prie jos prisijungti reikia prieigos prie įrenginio ir papildomai galimybės ją konfigūruoti, todėl palaikoma VPN paslauga pradedama su tinklo administravimo teise arba naudoja privilegijuotą pagalbinę priemonę. Šis reikalavimas priklauso daimonui. Jis nieko nesako apie naršyklę, duomenų bazės klientą ar failų perdavimo įrankį. Paslauga, kuriai reikia šios galimybės, jos reikia savo sąrankos žingsniui, o ne savo klientams.

Kai maršrutas ir politika yra vietoje, įprastas procesas naudoja gautą kelią savo įprastais lizdo iškvietimais. Jam nereikia įrenginio mazgo ir nereikia root.

Įrenginio leidimų keitimas nėra būdas suteikti programai prieigą prie paskirties. Tai tik perkelia įrenginio ribą kitur.

Patikrinkite, kurioje vardų erdvėje programa iš tikrųjų veikia

Konteineris arba antra tinklo vardų erdvė savo procesams suteikia atskirą sąsajų rinkinį ir maršrutų lentelę. Tunelis hoste ten automatiškai neatsiranda, ir jokie įrenginio leidimų pakeitimai to nepakeis. Programa tiesiog maršrutizuos per tai, ką suteikia ta vardų erdvė. Todėl konteinerio atvaizdas negali atsitiktinai paveldėti hosto tunelio.

Patikrinkite su ip netns list ir ip -n NAME route, arba apžiūrėdami proceso vardų erdvės nuorodą. Atsakymas paprastai matomas viena komanda.

Dviem to paties hosto naudotojams politika taip pat gali būti suteikti skirtingi keliai. Tai tinklo sprendimas, o ne įrenginio nuosavybės įrodymas.

Atskirkite galimybes nuo tinklo politikos

Kai kuriems įrankiams reikia daugiau nei lizdo. Paketų fiksavimui reikia neapdoroto lizdo, o maršrutų keitimui reikia administravimo teisės. Tai atskiros operacijos su atskirais leidimais, ir vienos suteikimas neturėtų būti skaitomas kaip bendras reikalavimas naudoti VPN.

Programa, kuri įgyvendina savo tunelį, yra trečias atvejis. Ji tikrai atidaro TUN, nes prisiima daimono vaidmenį, todėl jai reikia daimono privilegijų.

Įvardykite operaciją prieš įvardydami privilegiją. Paprastai juos atskirti lengviau, nei atrodo.

Patikrinkite atskyrimą dviem paskyromis

Prijunkite tunelį kaip paslaugą, tada paleiskite programą kaip įprastą naudotoją ir patvirtinkite, kad ji pasiekia privatų išteklių. Patikrinkite ip route get paskirčiai iš to naudotojo apvalkalo, kad pamatytumėte, kuri sąsaja buvo pasirinkta. Jei maršrutas teisingas, o ryšys vis tiek nepavyksta, problema yra politika, o ne privilegija.

Gautas dizainas yra mažiausia privilegija su aiškia riba: vienas komponentas valdo sąranką ir tunelio išteklius, darbo krūviai išlaiko įprastas paskyras, o tinklo politika sprendžia, kas gali praeiti. Viską paleidus kaip root, tie vaidmenys sugriūva nieko nepaaiškinus.