OpenVPN'de önceden oluşturulmuş tun: iki sahiplik modelinin karşılaştırması

Birisi tun1 oluşturmuş, profil dev tun1 diyor ve bağlantı hâlâ bağlanmıyor. Adın ana makinede var olması neredeyse hiçbir şey söylemez, çünkü bağlanma ad alanına, aygıt türüne, bağlantıya kimin sahip olduğuna ve daemon'a neye izin verildiğine bağlıdır. Bir aygıtı yeniden kullanmak, varsayılan yapılandırmanın gizlediği bir kararı da dayatır: adresleri ve yolları hangi bileşen yazar. İki düzenin arıza biçimleri yapılandırma satırlarından çok daha fazla farklıdır, bu yüzden profili düzenlemeden önce karar verin.

Ad, bağlanma değildir

dev tun1 OpenVPN'den o adlı arayüzü ister ve geleneksel kullanıcı alanı derlemeleri onu açmaya çalışır. Ad olağan tun ya da tap kalıbını izlemiyorsa profil eşleşen bir dev-type da gerektirir, çünkü tür hiçbir zaman bir dizgeden çıkarılmaz. TAP aygıtı başka etiketli bir TUN aygıtı değildir: yanlış olanı bağlamak ya hemen başarısız olur ya da kimsenin beklemediği çerçeveleri taşıyan bir bağlantı üretir. Türü her şeyden önce denetleyin, çünkü sonraki her denetim iki tarafın bu konuda anlaştığını varsayar. Ardından sürecin aygıtı gerçekten açabildiğini, yalnızca göremediğini doğrulayın.

dev tun1
dev-type tun

Ağ arayüzü ve /dev/net/tun farklı nesnelerdir: biri ad alanı içindeki bir bağlantı, diğeri kullanıcı alanındaki bir programın bağlanmak için kullandığı karakter aygıtıdır. Linux TUN/TAP belgeleri bu bağlanma yolunu ve kalıcı aygıtlar için sahiplik kurallarını açıklar. ip link çalıştırabilen bir root kabuğu yalnızca kabuğun ayrıcalıkları olduğunu kanıtlar, daemon'ın olduğunu değil. Aygıt düğümünün sahipliği, hizmetin yetenek kümesi ve altında çalıştığı kullanıcı açılış başarılı olmadan önce hepsinin uyuşması gerekir.

Var olan ve açılamayan bir aygıt sahiplik sorunudur, yönlendirme sorunu değildir. Hata ayıklarken onu böyle ele alın, yoksa öğleden sonra hiçbir zaman sorun olmayan yönlendirme tablolarını okumakla geçer.

Bağlantıyı kim yapılandırır: iki sahiplik modeli

İlk modelde OpenVPN, bağlantıyı kaldırmanın parçası olarak adresleri ve yolları yapılandırır. Bu varsayılan davranıştır ve üzerinde düşünmesi en kolay olanıdır, çünkü tek bir bileşen durumu oluşturur ve sonra yeniden kaldırır. İkinci modelde arayüzün sahibi harici bir yöneticidir ve ifconfig-noexec OpenVPN'in adres yapılandırma komutlarını çalıştırmasını engelleyip parametreleri betiklere verir. Yönetici o zaman doğru yerel ve eş yapılandırmayı kendisi uygulamak zorundadır, bu da seçeneğin adının ima ettiğinden daha fazla iştir. İkisi arasında seçim yapmak, bağlantı ayaktayken onu kimin değiştirebileceği sorusudur.

ifconfig-noexec yalnızca adresleri kapsar: yönlendirme tablosuna dokunulmaz ve yol yapılandırması route-noexec'a aittir. İki direktifi ayrı sahipleri olan ayrı denetimler olarak ele alın, çünkü birini ayarlayıp diğerini varsaymak yarı yapılandırılmış bağlantıların yaygın kaynağıdır. Her katman için tam olarak bir sahip seçin, adresler tek yerde ve yollar tek yerde. Ağ yöneticisi ile VPN yardımcısının ikisinin de adres yazması, bir bağlantı kesintisinin diğer tarafın hâlâ bağlı olduğu durumu silme biçimidir.

Aygıtı önemli olan ad alanından inceleyin

Aygıtı VPN sürecinin çalıştığı ad alanından inceleyin, kabuğunuzun tesadüfen bulunduğu ad alanından değil. Aşağıdaki iki komut farklı sorulara yanıt verir ve fark, bir ana makine bir kapsayıcının görmediği bir arayüzü gördüğünde ortaya çıkar. Bunları verilen sırayla çalıştırın, çünkü ikincisi ancak bağlantının var olup olmadığını bildikten sonra anlam kazanır.

ip -details link show dev tun1
ip tuntap show

İlk komut bağlantıyı çekirdeğin gördüğü gibi yazdırır, bayraklar ve arayüz türü dahil, ve böylece bunun amaçladığınız aygıt olduğunu doğrularsınız. İkincisi kalıcı tun/tap girişlerini listeler, bunlar hiçbir süreç tutmadan var olur. Kendisine atanan sahibini bekleyen arayüz, başka bir VPN'e bağlı canlı bir tünelden farklı bir durumdur ve yalnızca ikincisi kendi bağlanmanızın neden başarısız olduğunu açıklar. Bir şeyi değiştirmeden önce aygıtı tutan süreci bulun, çünkü kalıcı giriş ile meşgul arayüzün düzeltmeleri farklıdır.

Çok kuyruk desteği kendi gereksinimleri olan belirli bir sürücü düzenidir, ilgisiz süreçlerin tek bir arayüzü paylaşmasına izin değildir. Başka bir sahibin canlı oturumu bir eşgüdüm sorunudur ve hiçbir profil düzenlemesi bunu çözmez.

İki tür kalıcılık

Çekirdek kalıcılığı ve persist-tun karıştırılması kolay ve yanlış anlaşılması pahalı ömürleri tanımlar. Kalıcı bir aygıt herhangi bir süreçten bağımsız olarak vardır, bu yüzden durdurmayı atlatır ve sonraki başlatma onu yeniden kullanabilir. persist-tun kaynakları tek bir OpenVPN süreci içinde desteklenen yumuşak yeniden başlatmalar boyunca korur, çok daha kısa bir ufuk. İkisi de hizmeti durdurmanın yolları ve adresleri yerinde bıraktığını vaat etmez ve görünür kalan bir arayüz çalışan şifreli bir oturumun kanıtı değildir.

Backend'i de doğrulayın, çünkü önceden oluşturulmuş bir arayüz onu hangi uygulamanın açacağı hakkında hiçbir şey söylemez. Doğrudan veri yolunu taşıyan topluluk derlemeleri, tasarım aksini söylemiyorsa onu kullanmayı deneyecektir. Sürümün bu anahtarı desteklediği yerlerde disable-dco bunun yerine kullanıcı alanı yolunu seçer; eski motorlar ve diğer istemciler böyle bir direktife sahip değildir, bu yüzden sürüm koşulunu seçeneğin yanında tutun, geçerli olduğunu varsaymayın.

Yalnızca başlatma sınandığında ne kırılır

Bir sahiplik anlaşması ilk testi geçip sonuncusunda başarısız olabilir, bu da başlatmayı tek başına zayıf bir denetim yapar. Bunun yerine iki geçişi izleyin: yumuşak bir yeniden başlatma ve ardından başlatma gelen tam bir durdurma.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Başlatma kolay durumdur: birim ayağa kalkar, bağlantı görünür ve durum çıktısı yüklenen profili adlandırır. Bağlanma, daemon'ın aygıtı açtığı andır, bu yüzden bağlantı denetimini birim etkin olduğunu bildirdikten sonra çalıştırın, öncesinde değil. Durum hâlâ etkinleşirken bağlantı varsa, henüz kimsenin bağlanmadığı kalıcı bir aygıta bakıyorsunuz, çalışan bir tünele değil. Devam etmeden önce bağlantıdan gerçek trafik geçirin, çünkü kullanılabilir yolu olmayan bağlı bir arayüz hâlâ başarısızlıktır.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Yumuşak bir yeniden başlatma oturumu kullanılabilir ve kaynakları sağlam bırakmalıdır ve persist-tun tam olarak bu işi yapar. Tam durdurma, harici bir yöneticinin kendini belli ettiği yerdir: bağlantı veya adresleri durdurmayı atlatırsa onlara başka biri sahiptir ve bu ya belgelediğiniz durumdur ya da az önce bulduğunuz hatadır. İki gözlemi de profilin yanına not edin, böylece sonraki değişiklik bir diyagramdan değil kanıttan başlar.