Docker'daki OpenVPN /dev/net/tun dosyasını açamıyor: ne eksik

Konteyner imajları ihtiyaç duydukları her OpenVPN ikili dosyasını ve yapılandırma dosyasını taşıyabilir ve yine de ilk ağ çağrısında başarısız olabilir. Hata /dev/net/tun adını verir çünkü uygulama çekirdekten bir TUN arayüzü istedi ve konteynerde ne aygıt düğümü ne de onu oluşturma yeteneği vardı. Bunlar iki ayrı izindir ve birini düzeltmek diğerini tam olduğu yerde bırakır.

Onları ayırmak her biri için bir komut gerektirir. Sonraki hata mesajı hangi sınırda durduğunuzu söyler.

Aygıt düğümü ve yetenek iki kapıdır

Aygıt düğümü bir dosya sistemi nesnesidir, bu yüzden konteynerin onu kendi bağlama ad alanında görmesi gerekir. Yetenek bir izindir, bu yüzden süreç arayüzün oluşturulacağı ad alanında CAP_NET_ADMIN gerektirir. Aygıtı yetenek olmadan geçirmek size açılan bir düğüm ve başarısız olan bir ioctl verir. Yeteneği aygıt olmadan vermek uygulamayı hiçbir şey açamaz durumda bırakır, bu yüzden ikisi örneklerde genellikle birlikte görünür.

Docker'ın devices ayarı ana makinenin aygıtını konteynere eşler, cap_add ise yetenek kümesini ayarlar. Aynı yolun bind mount'u dosyayı aygıt erişimi semantiğini uygulamadan görüş alanına koyar.

Bunu Compose dosyasının dışında yeniden üretin

Hizmeti düzenlemeden önce ana makinede aygıt olduğunu ve çıplak bir konteynerin arayüz oluşturabildiğini kontrol edin. Aşağıdaki komut bilerek asgari düzeydedir ve tek amacı bir ana makine sorununu compose sorunundan ayırmaktır. Başarısız olursa hiçbir compose değişikliği yardımcı olmaz.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

Ana makinede düğümün olmaması tun modülünün kullanılamadığı anlamına gelir; bu konteynerin değil ana makinenin tarafındaki bir düzeltmedir. Düğüm varken konteyner içinde açılamaması aygıt erişimine işaret eder ve mesaj no such file yerine permission denied der. Bu iki başarısızlığın sırası tüm teşhistir. Herhangi bir bayrağı değiştirmeden önce hangisini gördüğünüzü yazın.

TUN sonrası hatalar farklı sorunlardır

Arayüz göründüğü anda bir sonraki başarısızlığın sahibi başkadır. Kimlik doğrulama hataları tünelin sunucuya ulaştığı ve kimlik bilgilerinin reddedildiği anlamına gelir, bu yüzden yetenek değişiklikleri yardımcı olmaz. Uygulamalar hâlâ başarısızken tünel kuruluyorsa bu rotalara, iletmeye, konteyner içindeki DNS çözümlemesine veya konteynerin kendi ağ düzenine işaret eder. Bunların her biri TUN izninin yanıtlayamayacağı sıradan bir ağ sorusudur. Her değişiklikten sonra ilk testi yinelemek başarısızlıkların tek bir izlenimde birleşmesini önler.

Çalışan bir örnekten her ayarı kopyalamak, asgari bir düzeltmenin okunamaz bir hizmet tanımına dönüşme yoludur. Yalnızca bu dağıtımın ihtiyaç duyduklarını getirin ve her birinin neden orada olduğunu kaydedin.

Arayüzü konteynerin içinde doğrulayın

Arayüzü ve yetenek kümesini kontrol edin ana makineden değil, çalışan konteynerin içinden. Aşağıdaki komutlar aygıt düğümünü, yetenek listesini ve bir arayüzün oluşturulup oluşturulamayacağını gösterir. Bunları istemciyi çalıştıran aynı konteynerde çalıştırın ve imaj asgariyse araçları kurun.

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

bounding set içinde olup effective set içinde olmayan bir yetenek, hiç verilmemiş olandan farklı davranır ve capsh ikisini de gösterir. Düğüm varsa ve yetenek oradaysa ama oluşturma hâlâ başarısızsa, çalışma zamanı işlemi kısıtlayan seccomp profili veya AppArmor politikası gibi başka bir şey uyguluyordur. Bu, uygulama değil çalışma zamanı tarafından belgelenen üçüncü sınırdır.

Konteyner bayraklarını, imajı ve her denemenin tam hatasını kaydedin. O notu okuyan sonraki kişi tüm soruşturmayı yinelemeden hangi kapının kapalı olduğunu söyleyebilir.