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

Pregledač koji koristi uspostavljeni Linux VPN ne otvara /dev/net/tun. Otvara socket, a kernel odlučuje kroz koje sučelje izlaze paketi tog socketa. Proces koji je stvorio tunel obavlja drugi posao od procesa čiji promet prenosi. Držanje tih dviju uloga odvojenima odgovara na većinu pitanja o dozvolama prije nego što se postave.

Prati jedan paket od socketa do tunela

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

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

Nacrtaj dvije polovice jednom i pitanja o dozvolama postat će lakše smjestiti. Gornja polovica je svijet aplikacija, a donja pripada daemonu.

Odlučite kome treba uređaj, a kome ne

Stvaranje TUN sučelja ili pridruživanje njemu zahtijeva pristup uređaju i uz to sposobnost da se konfigurira, zato podržana VPN usluga počinje s ovlaštenjem mrežne administracije ili koristi privilegiranog pomoćnika. Taj zahtjev pripada daemonu. Ne govori ništa o pregledaču, klijentu baze podataka ili alatu za prijenos datoteka. Usluga kojoj treba ta sposobnost treba je za vlastiti korak podešavanja, a ne za svoje klijente.

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

Promjena dozvola uređaja nije način da se aplikaciji da pristup odredištu. Samo premješta granicu uređaja negdje drugdje.

Provjerite u kojem imenskom prostoru aplikacija stvarno radi

Konteiner ili drugi mrežni imenski prostor daje svojim procesima odvojen skup sučelja i tablicu ruta. Tunel na hostu ne pojavljuje se ondje automatski i nikakva promjena dozvola uređaja to ne mijenja. Aplikacija će jednostavno usmjeravati kroz ono što taj imenski 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 procesa. Odgovor je obično vidljiv u jednoj naredbi.

Dvojici korisnika na istom hostu politika također može dati različite putove. To je mrežna odluka, a ne dokaz o vlasništvu uređaja.

Odvojite sposobnosti od mrežne politike

Nekim alatima treba više od socketa. Snimanje paketa treba sirovi socket, a promjena ruta treba administrativno ovlaštenje. To su odvojene operacije s odvojenim dopuštenjima, i davanje jedne ne treba čitati kao opći uvjet za korištenje VPN-a.

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

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

Provjerite podjelu s dva računa

Povežite tunel kao uslugu, zatim pokrenite aplikaciju kao običnog korisnika i potvrdite da dolazi do privatnog resursa. Provjerite ip route get za odredište iz shell-a tog korisnika da vidite koje je sučelje odabrano. Ako je ruta ispravna, a veza ipak ne uspijeva, problem je politika, a ne privilegija.

Rezultirajući dizajn je najmanja privilegija s izričitom granicom: jedna komponenta posjeduje podešavanje i resurse tunela, radna opterećenja zadržavaju svoje uobičajene račune, a mrežna politika odlučuje što smije proći. Pokretanje svega kao root ruši te uloge bez ikakva objašnjenja.