Obična Linux aplikacija koristi VPN bez diranja TUN-a

Preglednik koji koristi već uspostavljen Linux VPN ne otvara /dev/net/tun. On otvara socket, a jezgra odlučuje kroz koje sučelje odlaze paketi tog socketa. Proces koji je stvorio tunel obavlja drukčiji posao od procesa čiji promet prenosi. Držanje tih dviju uloga odvojenima odgovara na većinu pitanja o dopuštenjima prije nego što se postave.

Pratite jedan paket od socketa do tunela

Obična aplikacija poziva connect ili send, a jezgra traži rutu do odredišta. Ako odabrana ruta pokazuje na sučelje tunela, paket se stavlja u red uređaja koji čita VPN daemon. Daemon ga šifrira i šalje kroz fizičko sučelje. Svaka strelica u tom opisu mjesto je na kojem se može odgovoriti na pitanje o dopuštenjima.

Ništa na tom putu ne zahtijeva da aplikacija zna o uređaju. Daemon drži datotečni deskriptor i obavlja operacije sa sučeljem, dok aplikacija vidi samo uobičajeni mrežni API.

Nacrtajte dvije polovice jednom i pitanja o dopuštenjima postaju lakše smjestiti. Gornja polovica je svijet aplikacija, a donja pripada daemonu.

Odredite kome treba uređaj, a kome ne

Stvaranje TUN sučelja ili povezivanje s njim zahtijeva pristup uređaju plus ovlast za njegovo konfiguriranje, zato podržana VPN usluga počinje s ovlasti za administraciju mreže ili koristi privilegirani pomoćnik. Taj zahtjev pripada daemonu. On ne govori ništa o pregledniku, klijentu baze podataka ni alatu za prijenos datoteka. Usluga kojoj treba ta ovlast treba je za vlastiti korak postavljanja, ne za svoje klijente.

Kad su ruta i pravilo na mjestu, obični proces koristi dobiveni put kroz svoje uobičajene pozive socketa. Ne treba mu čvor uređaja i ne treba mu root.

Promjena dopuštenja uređaja nije način da se aplikaciji odobri pristup odredištu. Ona samo premješta granicu uređaja na drugo mjesto.

Provjerite u kojem imenskom prostoru aplikacija stvarno radi

Kontejner ili drugi mrežni imenski prostor daje svojim procesima zaseban skup sučelja i tablicu ruta. Tunel na hostu ne pojavljuje se tamo automatski i nikakva promjena dopuštenja uređaja to ne mijenja. Aplikacija će jednostavno ići kroz ono što taj prostor pruža. Zato kontejnerska slika ne može slučajno naslijediti tunel hosta.

Provjerite s ip netns list i ip -n NAME route ili pregledom veze imenskog prostora za proces. Odgovor je obično vidljiv u jednoj naredbi.

Dva korisnika na istom hostu također mogu dobiti različite putove pravilom. To je mrežna odluka, a ne dokaz o vlasništvu nad uređajem.

Odvojite ovlasti od mrežnog pravila

Neki alati trebaju više od socketa. Snimanje paketa treba sirovi socket, a promjena ruta treba administrativnu ovlast. To su odvojene operacije s odvojenim odobrenjima i odobrenje jedne ne treba čitati kao opći zahtjev za korištenje VPN-a.

Program koji sam implementira tunel treći je slučaj. On doista otvara TUN jer preuzima ulogu daemona, zato mu trebaju daemonove privilegije.

Imenujte operaciju prije nego imenujete privilegiju. Njih je obično lakše razdvojiti nego što izgleda.

Provjerite podjelu s dva računa

Spojite tunel kao usluga, zatim pokrenite aplikaciju kao običan korisnik i potvrdite da doseže privatni resurs. Provjerite ip route get za odredište iz ljuske tog korisnika da vidite koje je sučelje odabrano. Ako je ruta ispravna, a veza i dalje ne uspijeva, problem je u pravilu, a ne u privilegiji.

Rezultat je najmanja privilegija s jasnom granicom: jedna komponenta posjeduje postavljanje i resurse tunela, radna opterećenja zadržavaju svoje uobičajene račune, a mrežno pravilo odlučuje što smije proći. Pokretanje svega kao root sažima te uloge bez ikakva objašnjenja.