Sıradan bir Linux uygulaması TUN'a dokunmadan VPN kullanır

Kurulu bir Linux VPN'i kullanan bir tarayıcı /dev/net/tun aygıtını açmaz. Bir soket açar ve o soketin paketlerinin hangi arabirimden çıktığına çekirdek karar verir. Tüneli oluşturan süreç, taşıdığı trafiğin sürecinden farklı bir iş yapar. Bu iki rolü ayrı tutmak, izin sorularının çoğunu sorulmadan önce yanıtlar.

Bir paketi soketten tünele kadar izleyin

Sıradan bir uygulama connect veya send çağırır ve çekirdek hedef için bir yol arar. Seçilen yol tünel arabirimini gösteriyorsa paket, VPN daemon'ının okuduğu aygıtın kuyruğuna girer. Daemon onu şifreler ve fiziksel arabirimden dışarı gönderir. O açıklamadaki her ok, bir izin sorusunun yanıtlanabileceği bir yerdir.

O yolda hiçbir şey uygulamanın aygıtı bilmesini gerektirmez. Daemon dosya tanımlayıcısını tutar ve arabirim işlemlerini yapar, uygulama ise yalnızca normal bir ağ API'si görür.

İki yarıyı bir kez çizin, izin sorularını yerleştirmek kolaylaşır. Üst yarı uygulamalar dünyasıdır, alt yarı daemon'a aittir.

Aygıta kimin ihtiyacı olduğuna ve kimin olmadığına karar verin

Bir TUN arabirimi oluşturmak veya ona bağlanmak, aygıt erişimi ve buna ek olarak onu yapılandırma yeteneği gerektirir; bu yüzden desteklenen bir VPN hizmeti ağ yönetimi yetkisiyle başlar veya ayrıcalıklı bir yardımcı kullanır. Bu gereksinim daemon'a aittir. Tarayıcı, veritabanı istemcisi veya dosya aktarım aracı hakkında hiçbir şey söylemez. Yeteneğe ihtiyaç duyan hizmet, onu kendi kurulum adımı için ister, istemcileri için değil.

Yol ve politika yerine oturduğunda, sıradan bir süreç ortaya çıkan yolu olağan soket çağrılarıyla kullanır. Aygıt düğümüne ihtiyacı yoktur ve root'a da ihtiyacı yoktur.

Aygıt izinlerini değiştirmek, bir uygulamaya hedef erişimi vermenin yolu değildir. Yalnızca aygıt sınırını başka bir yere taşır.

Uygulamanın gerçekte çalıştığı ad alanını denetleyin

Bir konteyner veya ikinci bir ağ ad alanı, süreçlerine ayrı bir arabirim kümesi ve yönlendirme tablosu verir. Ana makinedeki bir tünel orada kendiliğinden görünmez ve hiçbir aygıt izni değişikliği bunu değiştirmez. Uygulama yalnızca o ad alanının sunduğu şey üzerinden yönlendirme yapar. Bu yüzden bir konteyner imajı ana makinenin tünelini kazara devralamaz.

Bunu ip netns list ve ip -n NAME route ile veya sürecin ad alanı bağlantısına bakarak denetleyin. Yanıt genellikle tek bir komutta görünür.

Aynı ana makinedeki iki kullanıcıya politika ile farklı yollar da verilebilir. Bu bir ağ kararıdır, aygıt sahipliğine dair kanıt değildir.

Yetenekleri ağ politikasından ayırın

Bazı araçlar bir soketten fazlasına ihtiyaç duyar. Paket yakalamak ham bir soket gerektirir, yolları değiştirmek ise yönetim yetkisi gerektirir. Bunlar ayrı izinlere sahip ayrı işlemlerdir ve birini vermek VPN kullanmanın genel bir koşulu olarak okunmamalıdır.

Kendi tünelini uygulayan bir program üçüncü durumdur. Daemon'ın rolünü üstlendiği için TUN'u gerçekten açar, bu yüzden daemon'ın ayrıcalıklarına ihtiyaç duyar.

Ayrıcalığı adlandırmadan önce işlemi adlandırın. İkisini ayırmak genellikle göründüğünden daha kolaydır.

Ayrımı iki hesapla doğrulayın

Tüneli hizmet olarak bağlayın, ardından uygulamayı sıradan bir kullanıcı olarak çalıştırın ve özel kaynağa ulaştığını doğrulayın. O kullanıcının kabuğundan hedef için ip route get komutunu denetleyerek hangi arabirimin seçildiğini görün. Yol doğruysa ve bağlantı hâlâ başarısız oluyorsa sorun ayrıcalık değil politikadır.

Ortaya çıkan tasarım, açık bir sınırla en az ayrıcalıktır: bir bileşen kuruluma ve tünel kaynaklarına sahiptir, iş yükleri olağan hesaplarını korur ve ağ politikası neyin geçebileceğine karar verir. Her şeyi root olarak çalıştırmak, hiçbir şey açıklamadan bu rolleri çökertir.