Docker-də OpenVPN /dev/net/tun faylını aça bilmir: nə çatışmır

Konteyner obrazları ehtiyac duyduqları bütün OpenVPN binar fayllarını və konfiqurasiya fayllarını daşıya bilər və yenə də ilk şəbəkə çağırışında uğursuz olar. Xəta /dev/net/tun adını çəkir, çünki tətbiq nüvədən TUN interfeysi istədi və konteynerin nə cihaz node-u, nə də onu yaratmaq imkanı var idi. Bunlar iki ayrı icazədir və birini düzəltmək digərini tam olduğu yerdə qoyur.

Onları ayırmaq hər biri üçün bir əmr tələb edir. Sonrakı xəta mesajı sizə əslində hansı sərhəddə dayandığınızı deyir.

Cihaz node-u və imkan iki qapıdır

Cihaz node-u fayl sistemi obyektidir, buna görə konteyner onu öz mount namespace-ində görməlidir. İmkan bir icazədir, buna görə proses interfeysin yaradılacağı namespace-də CAP_NET_ADMIN tələb edir. Cihazı imkan olmadan ötürmək sizə açılan node və uğursuz olan ioctl verir. İmkanı cihaz olmadan vermək tətbiqi heç nəyi aça bilməyəcək vəziyyətdə qoyur, buna görə nümunələrdə ikisi adətən birlikdə görünür.

Docker-in devices ayarı host cihazını konteynerə əks etdirir, cap_add isə imkan dəstini tənzimləyir. Eyni yolun bind mount-u faylı cihaz giriş semantikası tətbiq etmədən görünüşə qoyur.

Bunu Compose faylından kənarda təkrarlayın

Xidməti redaktə etməzdən əvvəl host-un cihaza sahib olduğunu və sadə konteynerin interfeys yarada bildiyini yoxlayın. Aşağıdakı əmr qəsdən minimaldır və yeganə məqsədi host problemini compose problemindən ayırmaqdır. Uğursuz olarsa, heç bir compose dəyişikliyi kömək etməyəcək.

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'

Host-da node-un olmaması tun modulunun mövcud olmadığını bildirir, bu konteyner deyil, host tərəfində düzəlişdir. Mövcud olan, lakin konteyner daxilində açıla bilməyən node cihaz girişinə işarə edir və mesaj no such file əvəzinə permission denied deyəcək. Bu iki uğursuzluğun sırası bütün diaqnozdur. Hər hansı bayraq dəyişməzdən əvvəl hansını gördüyünüzü yazın.

TUN-dan sonrakı xətalar fərqli problemlərdir

İnterfeys görünən kimi növbəti uğursuzluğun fərqli sahibi olur. Autentifikasiya xətaları tunelin serverə çatdığını və etimad məlumatlarının rədd edildiyini bildirir, buna görə imkan dəyişiklikləri kömək etməyəcək. Tətbiqlər hələ də uğursuz olarkən qurulan tunel marşrutlara, yönləndirməyə, konteyner daxilində DNS həllinə və ya konteynerin öz şəbəkə düzümünə işarə edir. Bunların hər biri TUN icazəsinin cavab verə bilmədiyi adi şəbəkə sualıdır. Hər dəyişiklikdən sonra ilkin testi təkrarlamaq uğursuzluqların bir təəssürata birləşməsinin qarşısını alır.

İşləyən nümunədən hər ayarı köçürmək minimal düzəlişin oxunmaz xidmət tərifinə çevrilmə yoludur. Yalnız bu yerləşdirmənin ehtiyac duyduqlarını götürün və hər birinin nə üçün orada olduğunu qeyd edin.

İnterfeysi konteynerin daxilində yoxlayın

İnterfeysi və imkan dəstini yoxlayın host-dan deyil, işləyən konteynerin daxilindən. Aşağıdakı əmrlər cihaz node-unu, imkan siyahısını və ümumiyyətlə interfeys yaratmağın mümkün olub-olmadığını göstərir. Onları klienti işlədən konteynerin özündə çalışdırın və obraz minimaldırsa, alətləri quraşdırın.

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

Bounding set-də olub effektiv set-də olmayan imkan heç vaxt verilməmiş imkandan fərqli davranır və capsh hər ikisini göstərir. Node varsa və imkan oradadırsa, lakin yaratma hələ də uğursuz olursa, runtime əməliyyatı məhdudlaşdıran seccomp profili və ya AppArmor siyasəti kimi başqa bir şey tətbiq edir. Bu, tətbiq deyil, runtime tərəfindən sənədləşdirilən üçüncü sərhəddir.

Konteyner bayraqlarını, obrazı və hər cəhdin dəqiq xətasını qeyd edin. Həmin qeydi oxuyan növbəti şəxs bütün araşdırmanı təkrarlamadan hansı qapının bağlı olduğunu deyə bilər.