Linux aplikazio arrunt batek VPN-a erabiltzen du TUN ukitu gabe

Linux VPN bat ezarrita erabiltzen duen nabigatzaile batek ez du /dev/net/tun irekitzen. Socket bat irekitzen du, eta kernelak erabakitzen du socket horren paketeak zein interfazetik ateratzen diren. Tunela sortu zuen prozesuak beste lan bat egiten du berak garraiatzen duen trafikoaren prozesuak baino. Bi rol horiek bereizita edukitzeak baimen-galdera gehienei erantzuten die egin baino lehen.

Jarraitu pakete bat socket-etik tunelera

Aplikazio arrunt batek connect edo send deitzen du, eta kernelak helmugarako bide bat bilatzen du. Aukeratutako bideak tunelaren interfazera seinalatzen badu, paketea VPN daemon-ak irakurtzen duen gailuan jartzen da ilaran. Daemon-ak zifratu eta interfaz fisikoaren bidez bidaltzen du. Deskribapen horretako gezi bakoitza baimen-galdera bat erantzun daitekeen tokia da.

Bide horretan ezerk ez du eskatzen aplikazioak gailua ezagutzea. Daemon-ak fitxategi-deskribatzailea gordetzen du eta interfaze-eragiketak egiten ditu; aplikazioak sare-API normal bat baino ez du ikusten.

Marraztu bi erdiak behin, eta baimen-galderak errazago kokatuko dira. Goiko erdia aplikazioen mundua da, eta behekoa daemon-arena.

Erabaki nork behar duen gailua eta nork ez

TUN interfaz bat sortzeak edo horri atxikitzeak gailuaren sarbidea behar du eta gainera hura konfiguratzeko gaitasuna, eta horregatik VPN zerbitzu onartu batek sare-administrazioaren autoritatearekin hasten da edo laguntzaile pribilegiatu bat erabiltzen du. Betebehar hori daemon-arena da. Ez du ezer esaten nabigatzaileaz, datu-baseko bezeroaz edo fitxategi-transferentziako tresnaz. Gaitasuna behar duen zerbitzuak bere konfigurazio-urratserako behar du, ez bere bezeroentzat.

Bidea eta politika ezarri ondoren, prozesu arrunt batek lortutako bidea erabiltzen du bere socket deialdi ohikoen bidez. Ez du gailu-nodoa behar, ez eta root ere.

Gailuaren baimenak aldatzea ez da aplikazio bati helmugarako sarbidea emateko modu bat. Gailuaren muga beste toki batera eramaten du soilik.

Egiaztatu aplikazioa benetan exekutatzen den izen-espazioa

Edukiontzi batek, edo bigarren sare-izen-espazio batek, interfaze multzo eta bide-taulaketa bereiziak ematen dizkie bere prozesuei. Ostalariaren tunel bat ez da hor agertzen automatikoki, eta gailuaren baimenen aldaketek ez dute hori lortzen. Aplikazioak izen-espazio horrek eskaintzen duenaren bidez bideratuko du besterik gabe. Horregatik edukiontzi-irudi batek ezin du ostalariaren tunel bat istripuz heredatu.

Egiaztatu ip netns list eta ip -n NAME route erabiliz, edo prozesuaren izen-espazioaren esteka ikusiz. Erantzuna komando bakarrean ikusten da normalean.

Ostalari beraren bi erabiltzaileri bide desberdinak eman dakizkieke politikaren bidez. Sare-erabakia da, ez gailuaren jabetzaren froga.

Bereizi gaitasunak sare-politikatik

Tresna batzuek socket bat baino gehiago behar dute. Paketeak harrapatzeko socket gordin bat behar da, eta bideak aldatzeko administrazio-autoritatea. Eragiketa bereiziak dira, emate bereiziekin, eta bat ematea ez litzateke VPN-a erabiltzeko baldintza orokortzat hartu behar.

Bere tunela inplementatzen duen programa hirugarren kasua da. TUN benetan irekitzen du daemon-aren rola hartzen duelako, eta horregatik behar ditu daemon-aren pribilegioak.

Izenda ezazu eragiketa pribilegioa izendatu aurretik. Biak errazago bereizten dira itxuraz baino.

Egiaztatu banaketa bi konturekin

Konektatu tunela zerbitzu gisa, gero exekutatu aplikazioa erabiltzaile arrunt gisa eta egiaztatu baliabide pribatura iristen dela. Egiaztatu ip route get helmugarako erabiltzaile horren shell-etik zein interfaz aukeratu zen ikusteko. Bidea zuzena bada eta konexioak huts egiten badu oraindik, arazoa politika da, ez pribilegioa.

Lortzen den diseinua gutxieneko pribilegioa da muga esplizituarekin: osagai batek konfigurazioa eta tunelaren baliabideak ditu, karga-lanek beren kontu normalak gordetzen dituzte, eta sare-politikak erabakitzen du zer igaro daitekeen. Dena root gisa exekutatzeak rol horiek bateratzen ditu ezer azaldu gabe.