nc -uz neden bir OpenVPN sunucusunun hazır olduğunu kanıtlayamaz

nc -uz ’u bir OpenVPN sunucusuna karşı çalıştırmak neredeyse hiçbir şey ölçmez ve OpenBSD kılavuzu bunu uyarılarında söyler: o kipteki UDP taramaları bir şey dinliyor olsun olmasın başarı bildirir. Çıkış durumu uzak durumu değil yerel gönderimi yansıtır, bu yüzden ona güvenen bir gözetleyici, süreç tablosu inandırıcı göründüğü sürece ölü bir sunucuyu sağlıklı olarak işaretli tutar. Onu değiştirmek, denetimin hangi soruyu yanıtlaması gerektiğine karar vermekle başlar, çünkü süreç, dinleyici, kimlik doğrulama ve uygulamaya erişilebilirlik dört farklı gözlemdir. Bunlardan birini adlandıran bir denetim yararlıdır; dördünü de ima eden bir denetim yüktür.

Bir UDP denetiminin gözleyebildikleri ve gözleyemedikleri

nc -uz bir datagram gönderir ve çıkar; döndürdüğü durum yerel gönderimi tanımlar. Kapalı bir bağlantı noktası ICMP port unreachable ile yanıt verebilir, ancak bu tarama kipinin belgelenmiş davranışı bunu bir hataya dönüştürmez ve filtrelenmiş bir bağlantı noktası hiç yanıt vermez. Dolayısıyla sessizlik ve başarı çağıran için aynı anlama gelir.

Bu, denetimi sunucunun değil yerel yığının sınaması yapar. Ana makinenin erişilebilir olduğunu, bağlantı noktasının bağlandığını, OpenVPN sürecinin çalıştığını veya bir istemcinin kimlik doğrulayabileceğini ortaya koymaz. TCP bağlantı sınaması daha güçlüdür çünkü el sıkışma kesin bir yanıt verir, ama yalnızca kurulum gerçekten TCP’de dinliyorsa. Denetimi aynı numarada TCP’ye çevirmek var olmayabilecek bir dinleyiciyi sınar ve yalnızca UDP kullanan bir sunucuya karşı sağlıklı bir hizmeti düşürür.

Denetimi yapılandırılmış taşıma ile eşleştirmek, iki sonuçtan herhangi birine güvenmekten önce gelir. UDP kurulumu farklı bir sinyale ihtiyaç duyar, farklı bir protokole değil.

Üç çağıran, üç farklı soru

Hazır olma, kimin sorduğuna bağlıdır. Çökmüş bir süreci yeniden başlatan hizmet yöneticisi örneğin başladığını ve dinleyicisini bağladığını bilmelidir. Yük dengeleyici şimdi gelen bir istemcinin kabul edileceğini bilmelidir. İzleme sistemi gerçek bir ağdan gelen yolun hâlâ izin verilen bir kaynağa oturum taşıdığını bilmelidir.

Bunlar aynı denetim değildir ve tek bir denetim üçünü de dürüstçe kapsayamaz. Önce çağıranı seçin, sonra kanıtı.

Denetimi güncel örnekten kurun

OpenVPN bir örnek başlatmayı bitirdiğinde bir başlangıç satırı yazar ve o satır yerel başlangıç hakkında yararlı bir kanıttır. Onu eklenen bir dosyanın sonundan değil güncel başlangıçtan okuyun, çünkü geçen haftanın başarısı bir dakika önceki başarıyla tamamen aynı okunur. Sunucu, herhangi bir istemci hiç bağlanmadan önce de başlatmayı bitirebilir, bu yüzden satır kimlik doğrulama hakkında hiçbir şey söylemez.

Başlangıç denetimi için süreç durumunu güncel günlük kanıtıyla ve yapılandırılmış taşımaya uyan bir dinleyiciyle eşleştirin. Denetim, süreç çalışırken ama başlatmayı bitirmemişken başarısız olmalıdır; bu, günlük sorgusunun bu açılış ve bu birimle sınırlı olması gerektiği anlamına gelir.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Üç çıktı, üç iddia: birim etkin, bu açılış başlatma satırını üretti ve bir şey UDP bağlantı noktasını tutuyor. Hiçbiri bir istemcinin bağlanabileceğini söylemez. Bunları durum sayfasında ayrı tutun ki bir olay tek bir yeşil noktaya çökmesin.

Bilerek kırın ve denetimi izleyin

Bir denetim ancak başarısız olduğunu gördükten sonra güvenilirdir. Sunucuyu durdurun, denetimi çalıştırın ve beklediğiniz sonucu doğrulayın. Sonra yeniden başlatın ve denetimin başka hiçbir değişiklik olmadan toparlandığını doğrulayın.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Bloğu satır satır okuyun. netcat komutu exit=0 yazdırır, oysa hiçbir şey bağlı değildir; tek satırdaki bütün sorun budur. İlki ss hiçbir şey yazdırmaz, yeniden başlatma başarılı olur ve ikincisi ss dinleyiciyi yeniden gösterir. Denetiminiz durdurulmuş sunucuya karşı geçiyorsa yerel yığını ölçüyor demektir, başka bir şeyi değil.

Karşıt hata da önemlidir. Sağlıklı bir sunucuya karşı başarısız olan bir denetim hiç gerekli olmayan yeniden başlatmalara yol açar ve yeniden başlatma döngüsü kendi başına bir kesintidir. Denetimi üzerine işlem yapabilecek bir şeye bağlamadan önce iki yönü de sınayın.

Durum satırı ne söylemeli

Her denetimin hangi sınırı kapsadığını kaydedin: süreç, dinleyici, kimlik doğrulama veya uygulama. Bir denetim nadiren birden fazlasını kapsar ve bunları “up” diye sıkıştıran bir durum sayfası olay sırasında önemli olan farkı gizler. Ağ yolu için özel bir kimliğe sahip gerçek bir istemci kullanın, el sıkışmayı ve izin verilen zararsız bir işlemi tamamlamasına izin verin, sonra bağlantıyı kesin. Bu, denetim kanalını, kimlik doğrulama ilkesini ve dinleyiciyi tek adımda çalıştırır.

Bu kimliği gerçek kullanıcılardan ayrı tutun ve denetimin ihtiyaç duyduğu en düşük izinleri verin. Geniş erişimli bir hazır olma denetimi kolaylık için eklenmiş yeni bir saldırı yüzeyidir. Kimlik bilgilerini herhangi bir hesap gibi döndürün, çünkü kimlik doğrulamayı bırakan bir denetim, istemci kabul etmeyi bırakan bir sunucuyla tamamen aynı görünür.

Uyarı metninde sınırı adlandırın, böylece ilk müdahale eden birime, sokete, sertifikaya mı yoksa rotaya mı bakacağını bilsin. Neyi kanıtladığını söyleyemeyen bir denetime yanlış nedenle güvenilecek ve netcat denetimi ilk başta tam olarak böyle hayatta kaldı.