Isang ordinaryong Linux app ang gumagamit ng VPN nang hindi hinahawakan ang TUN

Ang browser na gumagamit ng naitatag na Linux VPN ay hindi nagbubukas ng /dev/net/tun. Nagbubukas ito ng socket, at ang kernel ang nagpapasya kung saang interface lumalabas ang mga packet ng socket na iyon. Ang prosesong gumawa ng tunnel ay may ibang trabaho kaysa sa prosesong dinadala nito ang trapiko. Ang paghihiwalay ng dalawang papel na ito ay sumasagot sa karamihan ng tanong tungkol sa pahintulot bago pa ito itanong.

Sundan ang isang packet mula sa socket hanggang sa tunnel

Ang ordinaryong app ay tumatawag ng connect o send, at naghahanap ang kernel ng ruta patungo sa destinasyon. Kung ang napiling ruta ay tumuturo sa interface ng tunnel, ang packet ay pumipila sa device na binabasa ng VPN daemon. Ini-encrypt ito ng daemon at ipinapadala sa labas sa pamamagitan ng pisikal na interface. Bawat arrow sa paglalarawang iyon ay isang lugar kung saan masasagot ang tanong tungkol sa pahintulot.

Walang anuman sa rutang iyon ang nangangailangan na malaman ng app ang device. Hinahawakan ng daemon ang file descriptor at ginagawa ang mga operasyon sa interface, samantalang ang app ay nakakakita lamang ng normal na network API.

Iguhit ang dalawang hati nang isang beses, at mas madaling ilagay ang mga tanong tungkol sa pahintulot. Ang itaas na hati ay mundo ng mga app, at ang ibabang hati ay pag-aari ng daemon.

Magpasya kung sino ang nangangailangan ng device at sino ang hindi

Ang paggawa o pagkonekta sa interface ng TUN ay nangangailangan ng access sa device at dagdag pa ang kakayahang i-configure ito, kaya nagsisimula ang sinusuportahang serbisyo ng VPN sa awtoridad sa pamamahala ng network o gumagamit ng privileged helper. Ang pangangailangang iyon ay pag-aari ng daemon. Wala itong sinasabi tungkol sa browser, database client o tool sa paglilipat ng file. Ang serbisyong nangangailangan ng kakayahan ay nangangailangan nito para sa sarili nitong hakbang sa setup, hindi para sa mga client nito.

Kapag nakalagay na ang ruta at patakaran, ginagamit ng ordinaryong proseso ang resultang landas sa pamamagitan ng dati nitong mga tawag sa socket. Hindi nito kailangan ang node ng device, at hindi nito kailangan ang root.

Ang pagbabago ng mga pahintulot sa device ay hindi paraan para bigyan ang app ng access sa destinasyon. Inililipat lamang nito ang hangganan ng device sa ibang lugar.

Suriin ang namespace kung saan talagang tumatakbo ang app

Ang container, o pangalawang namespace ng network, ay nagbibigay sa mga proseso nito ng hiwalay na set ng interface at talahanayan ng ruta. Ang tunnel sa host ay hindi lumilitaw doon nang kusa, at walang pagbabago sa pahintulot ng device ang makakabago niyon. Ang app ay magruruta lamang sa pamamagitan ng ibinibigay ng namespace na iyon. Kaya hindi maaaring mamana ng container image ang tunnel ng host nang aksidente.

Suriin gamit ang ip netns list at ip -n NAME route, o sa pamamagitan ng pagsusuri sa link ng namespace ng proseso. Ang sagot ay karaniwang nakikita sa isang utos.

Ang dalawang user sa parehong host ay maaari ring bigyan ng magkaibang landas sa pamamagitan ng patakaran. Iyon ay desisyon sa network, hindi ebidensya tungkol sa pagmamay-ari ng device.

Ihiwalay ang mga kakayahan sa patakaran ng network

Ang ilang tool ay nangangailangan ng higit pa sa socket. Ang paghuli ng mga packet ay nangangailangan ng raw socket, at ang pagbabago ng ruta ay nangangailangan ng awtoridad sa pamamahala. Ang mga ito ay hiwalay na operasyon na may hiwalay na pagbibigay, at ang pagbibigay ng isa ay hindi dapat basahin bilang pangkalahatang kailangan sa paggamit ng VPN.

Ang programang nagpapatupad ng sarili nitong tunnel ay ikatlong kaso. Talagang binubuksan nito ang TUN dahil tinatanggap nito ang papel ng daemon, kaya kailangan nito ang mga pribilehiyo ng daemon.

Pangalanan ang operasyon bago pangalanan ang pribilehiyo. Karaniwang mas madaling paghiwalayin ang dalawa kaysa sa itsura.

I-verify ang paghihiwalay gamit ang dalawang account

Ikonekta ang tunnel bilang serbisyo, pagkatapos ay patakbuhin ang app bilang ordinaryong user at kumpirmahing naaabot nito ang pribadong mapagkukunan. Suriin ang ip route get para sa destinasyon mula sa shell ng user na iyon upang makita kung aling interface ang napili. Kung tama ang ruta at nabibigo pa rin ang koneksyon, ang problema ay patakaran at hindi pribilehiyo.

Ang resultang disenyo ay pinakamababang pribilehiyo na may malinaw na hangganan: isang bahagi ang may-ari ng setup at mga mapagkukunan ng tunnel, pinapanatili ng mga workload ang kanilang normal na account, at ang patakaran ng network ang nagpapasya kung ano ang maaaring dumaan. Ang pagpapatakbo ng lahat bilang root ay iguguho ang mga papel na iyon nang walang ipinaliwanag.