LXD konteyneri /dev/net/tun aygıtını açamıyor mu? unix-char girdisini denetleyin

LXD, ana makinenin karakter aygıtını konteynere bir aygıt düğümü ekleyerek sunar, konuğa bunu oluşturmayı öğreterek değil. Konteynerde /dev/net/tun yoksa aygıt ana makinede olabilir ve konuk yine de açamayabilir. unix-char girdisi bu yolun yönetici tarafındaki yarısıdır ve bilinçli olarak ayrıcalıklı bir konteynerden daha dardır. Bu nedenle ana makine düğümü ile konteyner düğümü ayrı denetimleri hak eder.

Mekanizma gözden kaybolmayacak kadar kısa: LXD bir ana makine yolunu çözer, örnek içinde karşılık gelen bir düğüm oluşturur ve aygıtı konteynerin aygıt cgroup'una ekler. Ardından konuk sürecinin düğümü herhangi bir şey için kullanmak üzere kendi iznine ve yeteneğine ihtiyacı vardır.

unix-char girdisi gerçekte neyi değiştirir

unix-char aygıtı LXD'ye ana makinenin bir karakter aygıtını konteyner içinde seçilen bir yolda sunmasını söyler. Girdinin önemli üç parçası vardır: yöneticinin kullandığı aygıt etiketi, ana makinedeki source yolu ve konuğun gördüğü path. Yalnızca son ikisi aygıtın kendisini tanımlar. Bunlardan herhangi birindeki yazım hatası, istemcinin hiç açmadığı bir konumda düğüm oluşturur.

Ana makinede aygıt genellikle /dev/net/tun olur. Konteyner içinde aynı yolu koruyabilir veya başka bir yol seçebilirsiniz, ancak yol VPN istemcisinin beklediğiyle eşleşmelidir. /dev/net/tun yolunu korumak ikinci bir yapılandırma sorununu önler, çünkü çoğu istemci o yolu sormadan açar.

Yönetici girdiyi örnek başladığında veya aygıt sıcak takıldığında uygular. Konuğa sürücü kopyalamaz ve tünel arayüzü oluşturmaz. Düğümü görünür kılar ve konteynerin aygıt denetim grubu üzerinden erişime izin verir.

Aygıtı konuğun içinde değil, örnekte bildirin

Girdiyi LXD yönetim bağlamından ekleyin, örneği ve daha sonra tanıyacağınız bir etiketi adlandırın. vpnbox adlı bir konteyner için komut şudur:

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

tun etiketi örneğin yapılandırmasına özgüdür. Bir arayüz adı değildir ve konukta herhangi bir şeyle eşleşmesi gerekmez. Bir profil aynı aygıtı zaten sağlıyorsa, ikinci girdi eklemek fazlalık değil çakışma yaratır, bu yüzden önce etkin yapılandırmayı inceleyin.

Konteyner içindeki dosyaları düzenlemek yanlış katmandır. Başlangıç betiğindeki bir mknod ayrıcalıklı bir konteynerde çalışıyor gibi görünüp sonra yeniden oluşturmada kaybolabilir veya daha az ayrıcalıklı olanda başarısız olabilir. Örneğin aygıt kümesinin sahibi yöneticidir; düğümün sahibi de o olsun.

Sahiplik ve kipi konuk sürecine uydurun

unix-char girdisi konteyner içindeki düğüm için uid, gid ve mode değerlerini ayarlayabilir. Bunları VPN istemcisini çalıştıran hesaba uydurmak için kullanın; aygıtı her kullanıcıya açmak veya konteyneri ayrıcalıklı kipe geçirmek yerine.

Görünürlük izinle aynı şey değildir. root'a ait ve kipi 600 olan bir düğüm, ayrıcalıksız kullanıcı olarak çalışan hizmet tarafından görülür ve yine de onun tarafından açılamaz. Önce konuk hesabını denetleyin, sonra sahipliği o hesaba ayarlayın ve kipi istemcinin gerektirdiğinden daha geniş tutmayın.

Sürecin ayrıca bir tünel arayüzü yapılandırma yeteneğine ihtiyacı vardır, genellikle konteynerin ağ ad alanında CAP_NET_ADMIN. Aygıtı aktarmak bu yeteneği vermez ve yeteneği vermek aygıtı sağlamaz; bunlar bağımsız gereksinimlerdir.

Girdinin neyi vermediğini bilin

Görünür bir düğüm çalışan bir VPN değildir. İstemci paketi hâlâ kurulmalı, profil hâlâ geçerli olmalı ve hizmet hâlâ başlamalıdır. Kimlik doğrulama, rotalar ve DNS istemcinin işi olarak kalır ve oradaki bir hata aygıt girdisinin yanlış olduğunun kanıtı değildir.

systemd başka bir kısıtlama ekleyebilir. DeviceAllow içeren veya sertleştirilmiş aygıt ilkesi olan bir birim, konteyner yöneticisinin sağladığı düğüme erişimi reddedebilir. Düğüm varken hizmet izin hatası bildirdiğinde birimin aygıt ilkesini denetleyin ve konteyneri genişletmek yerine o ilkeyi değiştirin.

Sıcak takma isteğe bağlı ve açıktır. required=false içeren bir girdi kaynak yolu gerektirir ve ana makine aygıtı değiştikçe görünebilir veya kaybolabilir. Bu yaşam döngüsü gelip giden donanıma uygundur; VPN'in açılışta ihtiyaç duyduğu TUN aygıtı için isteğe bağlı bir girdi, hizmetin önkoşulu var olmadan başlamasına izin verebilir.

Görünürlüğü, açmayı ve arayüzü bu sırayla doğrulayın

Önce amaçlanan konteyner içindeki düğümü doğrulayın. Yol, ana ve alt numaralar ve sahiplik ana makine aygıtıyla ve eklediğiniz girdiyle eşleşmelidir. Düğümün olmaması, yöneticinin girdiyi uygulamadığı veya başka bir örneğe uyguladığı anlamına gelir.

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

Ardından hizmet hesabının onu açabildiğini doğrulayın. O hesap olarak yapılan kısa bir test, sahiplik sorununu hizmet sorunundan ayırır. Son olarak istemciyi başlatın ve bir tünel arayüzünün göründüğünü doğrulayın; tüm yolu yalnızca bu üçüncü adım kanıtlar, çünkü ilk ikisi geçebilirken istemci profili veya yeteneği hâlâ yanlış olabilir.

Değişiklik onaylandığında örneği, aygıt etiketini, ana makine kaynağını, konuk yolunu ve sahip hesabı kaydedin. Bu beş değer, sonraki yeniden oluşturma, taşıma veya profil değişikliğinin koruması gereken şeydir ve bağlamı olmayan bir izin hatasından çok daha kolay karşılaştırılır.