Ordinara Linuksa aplikaĵo uzas la VPN-on sen tuŝi TUN

Retumilo, kiu uzas jam starigitan Linuksan VPN-on, ne malfermas /dev/net/tun. Ĝi malfermas poŝon, kaj la kerno decidas, per kiu interfaco la pakaĵoj de tiu poŝo eliras. La procezo, kiu kreis la tunelon, faras alian laboron ol la procezo, kies trafikon ĝi portas. Teni tiujn du rolojn aparte respondas al plej multaj demandoj pri permesoj antaŭ ol ili estas faritaj.

Sekvu unu pakaĵon de la poŝo ĝis la tunelo

Ordinara aplikaĵo vokas connect aŭ send, kaj la kerno serĉas itineron al la celo. Se la elektita itinero montras al la tunela interfaco, la pakaĵo estas envicigita al la aparato, kiun la VPN-demono legas. La demono ĝin ĉifras kaj sendas ĝin eksteren tra la fizika interfaco. Ĉiu sago en tiu priskribo estas loko, kie oni povas respondi demandon pri permeso.

Nenio sur tiu vojo postulas, ke la aplikaĵo sciu pri la aparato. La demono tenas la dosierpriskribilon kaj plenumas la interfacajn operaciojn, dum la aplikaĵo vidas nur ordinaran retan API-on.

Desegnu la du duonojn unufoje, kaj demandoj pri permesoj fariĝas pli facile lokigeblaj. La supra duono estas la mondo de aplikaĵoj, kaj la malsupra apartenas al la demono.

Decidu, kiu bezonas la aparaton kaj kiu ne

Krei aŭ alkroĉiĝi al TUN-interfaco postulas aliron al la aparato plus la rajton ĝin agordi, kaj tial subtenata VPN-servo komenciĝas kun retadministra aŭtoritato aŭ uzas privilegian helpanton. Tiu postulo apartenas al la demono. Ĝi diras nenion pri la retumilo, la datumbaza kliento aŭ la dosiertransiga ilo. Servo, kiu bezonas la rajton, bezonas ĝin por sia propra agorda paŝo, ne por siaj klientoj.

Post kiam la itinero kaj la politiko estas en loko, ordinara procezo uzas la rezultan vojon per siaj kutimaj poŝaj vokoj. Ĝi ne bezonas la aparatan nodon, kaj ĝi ne bezonas root.

Ŝanĝi aparatajn permesojn ne estas maniero doni al aplikaĵo aliron al celo. Ĝi nur movas la aparatan limon aliloken.

Kontrolu, en kiu nomspaco la aplikaĵo efektive ruliĝas

Ujo, aŭ dua reta nomspaco, donas al siaj procezoj apartan interfacan aron kaj itineran tabelon. Tunelo sur la gastiganto ne aperas tie aŭtomate, kaj nenia ŝanĝo de aparataj permesoj tion ŝanĝas. La aplikaĵo simple itineros tra tio, kion tiu nomspaco provizas. Tial uja bildo ne povas hazarde heredi tunelon de la gastiganto.

Kontrolu per ip netns list kaj ip -n NAME route, aŭ per ekzameno de la nomspaca ligilo de la procezo. La respondo kutime videblas en unu komando.

Ankaŭ al du uzantoj sur la sama gastiganto povas esti donitaj malsamaj vojoj per politiko. Tio estas reta decido, ne pruvo pri posedo de la aparato.

Apartigu rajtojn de reta politiko

Iuj iloj bezonas pli ol poŝon. Kapti pakaĵojn bezonas krudan poŝon, kaj ŝanĝi itinerojn bezonas administran aŭtoritaton. Tiuj estas apartaj operacioj kun apartaj donoj, kaj doni unu ne devus esti legata kiel ĝenerala postulo por uzi la VPN-on.

Programo, kiu efektivigas sian propran tunelon, estas la tria kazo. Ĝi vere malfermas TUN, ĉar ĝi transprenas la rolon de la demono, do ĝi bezonas la privilegiojn de la demono.

Nomu la operacion antaŭ ol nomi la privilegion. Kutime estas pli facile apartigi ilin, ol ili ŝajnas.

Kontrolu la disigon per du kontoj

Konektu la tunelon kiel la servo, poste rulu la aplikaĵon kiel ordinara uzanto kaj konfirmu, ke ĝi atingas la privatan rimedon. Kontrolu ip route get por la celo el la ŝelo de tiu uzanto, por vidi, kiu interfaco estis elektita. Se la itinero estas ĝusta kaj la konekto tamen malsukcesas, la problemo estas politiko, ne privilegio.

La rezulta dezajno estas minimuma privilegio kun eksplicita limo: unu komponento posedas la agordon kaj la tunelajn rimedojn, la laborŝarĝoj tenas siajn normalajn kontojn, kaj reta politiko decidas, kio rajtas pasi. Ruli ĉion kiel root kunfalas tiujn rolojn sen klarigi ion.