Ayrıcalıklı kip neden bir VPN'in ihtiyacından daha geniş

Konteyner tünelini açmıyordu, bu yüzden ayrıcalıklı bayrak eklendi ve artık çalışıyor. Bu sıra yalnızca en az bir iznin eksik olduğunu kanıtladı ve hangisi olduğu hakkında hiçbir şey söylemiyor. Ayrıcalıklı kip, bir tünel arayüzünün ihtiyaç duyduğundan çok daha geniş bir yetenek kümesi ve aygıt erişimi verir.

Bayrağın gerçekte değiştirdiği şey

Ayrıcalıklı bir konteyner geniş yetenekler ve ana makinenin aygıtlarına erişim alır; bu, ağ yolunun gerektirdiğinden çok daha büyük bir izindir. Tam küme folklorla değil, çalışma zamanı ortamı tarafından belgelenir ve Docker'ın konteyner çalıştırma belgeleri mevcut ayrıcalık seçeneklerini açıklar. Bir kez okumak, tünelin bütünün küçük bir parçası olduğunu görmeye yeter.

İki daha dar gereksinim çoğu VPN konteynerini kapsar. Bir arayüzü yapılandırmak ağ yönetimi yeteneğini gerektirir ve tünel aygıtını açmak tam o aygıt düğümüne erişim gerektirir. Bunlar ayrı izinlerdir ve ikisi birlikte bile genel seçenekten dardır. Ayrıcalıklı kümenin geri kalanının tünelle hiçbir ilgisi yoktur. Gerçekten ana makine düzeyinde erişime ihtiyaç duyan iş yükleri için vardır ve bir VPN konteyneri genellikle bunlardan biri değildir.

Her hatayı tek bir önkoşulla eşleştirin

Hata iletisi, onu bastırmadan önce okursanız hangi önkoşulun eksik olduğunu söyler. Aygıt düğümüyle ilgili ileti aygıtı adlandırır, izin verilmeyen bir işlemle ilgili ileti bir yeteneği adlandırır ve bir modül veya sysctl ile ilgili ileti çekirdek desteğini adlandırır. Bunların her birinin farklı bir düzeltmesi vardır ve yalnızca biri bir yetenektir.

Eksik bir yapılandırma dosyası her yetenek verildikten sonra da eksik kalır, bu yüzden ayrıcalıklı kip bazen hiçbir şeyi değiştirmez. Konteyner başlar, tünel yine de başarısız olur ve gerçek hata hiçbir zaman izinlerle ilgili değildi. Çekirdek desteği üçüncü durumdur ve yanlış okunması en kolay olanıdır. Ana makinede yüklenmemiş bir modül, ayrıcalıksız bir konteynerin içinden yüklenemez ve konteyner içinde daha fazla yetenek vermek ana makinenin durumunu değiştirmez.

Belirtiyi değil gereksinimi denetleyin

İmajın belgelediği en küçük çağrıyla başlayın, onu çalıştırın ve hatanın tam metnini saklayın. Ardından her seferinde bir izin ekleyin ve hangi eklemenin sonucu değiştirdiğini not edin.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Aygıtı gören ve yeteneğe sahip olan ama yine de başarısız olan bir konteyner, sorunun başka bir yerde olduğunu söyler. Bu yararlı bir sonuçtur ve ayrıcalıklı kip onu gizlerdi.

Ana makinedeki aygıt izinlerini de denetleyin, çünkü doğru verilmiş bir aygıt düğümü yanlış grup sahipliğiyle eksik bir izinle aynı hatayı üretir.

İşe yarayan en dar izni kaydedin

Dağıtımın ihtiyaç duyduğu her aygıtı ve yeteneği, onları gerekçelendiren hatayla birlikte yazın. O kayıt, sonraki kişinin bir şeyi güvenle kaldırmasını sağlar ve bir konteyner ayrıcalıklı olarak bildirildiğinde bir denetçinin isteyeceği de odur.

Çevredeki bağlamı da gözden geçirin, çünkü ana makine ağı, ana makine bağlamaları ve çalışma zamanı seçenekleri her biri bir iznin etkisini genişletebilir. Hepsini birleştiren yalıtılmış bir laboratuvar çağrısı, ne kadar iyi çalışmış olursa olsun üretim yapılandırması değildir. Dağıtımı tamamlandı ilan etmeden önce uygulamayı, DNS davranışını ve bir tünel hatasını sınayın. Bir arayüz oluşturma izni bir çıkış politikası değildir ve mükemmel tünelleme yapabilen bir konteyner bile uygulamanın gönderdiği her şeyi yine yönlendirir.