Një aplikacion i zakonshëm Linux përdor VPN pa prekur TUN

Një shfletues që përdor një VPN Linux të vendosur nuk hap /dev/net/tun. Ai hap një socket, dhe kerneli vendos se nga cila ndërfaqe dalin paketat e atij socket-i. Procesi që krijoi tunelin bën një punë tjetër nga procesi të cilit i transporton trafikun. Mbajtja e këtyre dy roleve të ndara u përgjigjet shumicës së pyetjeve për lejet para se ato të bëhen.

Ndjek një paketë nga socket-i deri te tuneli

Një aplikacion i zakonshëm thërret connect ose send, dhe kerneli kërkon një rrugë drejt destinacionit. Nëse rruga e zgjedhur tregon ndërfaqen e tunelit, paketa vendoset në radhë te pajisja që lexon daemoni i VPN-së. Daemoni e kripton dhe e dërgon jashtë përmes ndërfaqes fizike. Çdo shigjetë në atë përshkrim është një vend ku mund t'i përgjigjesh një pyetjeje për leje.

Asgjë në atë rrugë nuk kërkon që aplikacioni ta njohë pajisjen. Daemoni mban përshkruesin e skedarit dhe kryen operacionet e ndërfaqes, ndërsa aplikacioni sheh vetëm një API normal rrjeti.

Vizato dy gjysmat një herë, dhe pyetjet për leje bëhen më të lehta për t'u vendosur. Gjysma e sipërme është bota e aplikacioneve, dhe gjysma e poshtme i përket daemonit.

Vendos kush ka nevojë për pajisjen dhe kush jo

Krijimi ose lidhja me një ndërfaqe TUN kërkon akses në pajisje dhe përveç kësaj aftësinë për ta konfiguruar, prandaj një shërbim VPN i mbështetur fillon me autoritetin e administrimit të rrjetit ose përdor një ndihmës të privilegjuar. Ai kërkesë i përket daemonit. Nuk thotë asgjë për shfletuesin, klientin e bazës së të dhënave ose mjetin e transferimit të skedarëve. Një shërbim që ka nevojë për aftësinë e ka atë për hapin e vet të konfigurimit, jo për klientët e tij.

Pasi rruga dhe politika janë në vend, një proces i zakonshëm përdor rrugën që rezulton përmes thirrjeve të tij të zakonshme të socket-it. Nuk ka nevojë për nyjen e pajisjes dhe nuk ka nevojë për root.

Ndryshimi i lejeve të pajisjes nuk është mënyrë për t'i dhënë një aplikacioni akses në destinacion. Ai thjesht e zhvendos kufirin e pajisjes diku tjetër.

Kontrollo hapësirën e emrave ku aplikacioni ekzekutohet vërtet

Një kontejner, ose një hapësirë e dytë emrash rrjeti, u jep proceseve të tij një grup ndërfaqesh dhe një tabelë rrugësh të veçantë. Një tunel në host nuk shfaqet atje automatikisht, dhe asnjë ndryshim i lejeve të pajisjes nuk e ndryshon këtë. Aplikacioni thjesht do të rrugëtojë përmes asaj që ofron ajo hapësirë emrash. Prandaj një imazh kontejneri nuk mund të trashëgojë aksidentalisht një tunel të hostit.

Kontrollo me ip netns list dhe ip -n NAME route, ose duke inspektuar lidhjen e hapësirës së emrave të procesit. Përgjigja zakonisht duket në një komandë të vetme.

Dy përdoruesve në të njëjtin host mund t'u jepen edhe rrugë të ndryshme me politikë. Ky është një vendim rrjeti, jo provë për pronësinë e pajisjes.

Ndaj aftësitë nga politika e rrjetit

Disa mjete kanë nevojë për më shumë se një socket. Kapja e paketave kërkon një socket të papërpunuar, dhe ndryshimi i rrugëve kërkon autoritet administrimi. Këto janë operacione të veçanta me dhënie të veçanta, dhe dhënia e njërës nuk duhet lexuar si kërkesë e përgjithshme për përdorimin e VPN-së.

Një program që zbaton tunelin e vet është rasti i tretë. Ai vërtet hap TUN sepse merr rolin e daemonit, prandaj ka nevojë për privilegjet e tij.

Emërto operacionin para se të emërtosh privilegjin. Të dy zakonisht ndahen më lehtë sesa duken.

Verifiko ndarjen me dy llogari

Lidh tunelin si shërbimin, pastaj ekzekuto aplikacionin si përdorues i zakonshëm dhe konfirmo se arrin burimin privat. Kontrollo ip route get për destinacionin nga shell-i i atij përdoruesi për të parë cilën ndërfaqe u zgjodh. Nëse rruga është e saktë dhe lidhja ende dështon, problemi është politika, jo privilegji.

Dizajni që rezulton është privilegji minimal me një kufi të qartë: një komponent zotëron konfigurimin dhe burimet e tunelit, ngarkesat e punës mbajnë llogaritë e tyre normale, dhe politika e rrjetit vendos çfarë mund të kalojë. Ekzekutimi i gjithçkaje si root i shemb këto role pa shpjeguar asgjë.