VPN uç noktaları izin listesi: unuttuğunuz DNS yenilemesi
Bir VPN ana bilgisayar adı için güvenlik duvarı istisnası canlı bir DNS aboneliği değildir. Kimin çözeceğine, kümenin ne zaman yenileneceğine ve başarısız bir aramanın ne yapması gerektiğine karar verin.
vpn.example.com'u güvenlik duvarı istisnasına yazmak DNS'e abone olmak gibi hissettirir. Genellikle yükleme sırasında bir çeviri olur, sonrasında kural adresleri tutar ve hiçbir şey onları yenilemez. Artık iki bileşen işi paylaşıyor: yanıt veren çözümleyici ve saklayan güvenlik duvarı. Uç nokta kesintilerinin çoğu bu devir hiç tasarlanmadığı yerde başlar.
Bir kuraldaki ana bilgisayar adı canlı abonelik değildir
Bazı araçlar yapılandırma yüklenirken adı çözer; diğerleri ana bilgisayar adını tutar ve kendi programlarına göre yeniden çözer; başkaları yalnızca adres kabul eder. Görünen yapılandırma nadiren hangisinin geçerli olduğunu söyler. Belge örnekleri genellikle yükleme durumunu varsayar, bu yüzden geçiş sırasında fark insanları şaşırtır. Bir adres değişikliğinin fark edileceğini varsaymadan önce uygulamanın davranışını okuyun, çünkü eski izin listesi çalışan bir liste gibi tamamen aynı görünür uç nokta taşınana kadar.
Doğru ana bilgisayarı adlandıran bir kural yine de yanlış adrese izin verebilir. Bu boşluk efsanedir, yazım hatası değil.
Önbellek TTL'i güvenlik duvarınızın zamanlayıcısı değildir
DNS kayıtlarının bir yaşam süresi vardır ve çözümleyiciler yanıtları o süre boyunca önbelleğe alır. DNS belirtimi bu önbellek davranışını tanımlar, ancak DNS verilerini yönetir, güvenlik duvarının ayrı adres deposunu değil. Kısa bir TTL olmayan yerde yenileme işi yaratmaz. Önbellekleme birden fazla katmanda da olur, bu yüzden bir terminalin gördüğü yanıt güvenlik duvarının gördüğü olmayabilir.
Gerçek ürüne üç soru sorun: ne zaman çözer, sonucu nerede saklar ve bir güncellemeyi ne tetikler. Yanıt yalnızca önyüklemedeyse, uzun ömürlü bir oturum kabul edildiği adresten daha uzun yaşayabilir.
dig +short vpn.example.com
resolvectl query vpn.example.com
Yenilemeyi ve hatayı tek bir politika olarak tasarlayın
Bakımı yapılan bir istisna açık yanıtlar gerektirir: istemci yeni bir adres seçmeden önce yenilemeyi ne tetikler, izin verilen küme geniş geçici bir pencere açmadan nasıl değişir ve eski girdiler ne zaman kaldırılır. Bu yanıtları kuralın yanına yazın.
Hata davranışını bilerek seçin. Eski adresi tutmak bir oturumu koruyabilir ve eski bir izin bırakabilir; kümeyi temizlemek kurtarmayı engelleyebilir. Hiçbiri başarısız bir aramanın rastlantısal sonucu olmamalıdır. Seçilen davranışı runbook'a yazın ki bir sonraki operatör baskı altında doğaçlama yapmasın.
Bootstrap DNS'i de dar tutun. Genel bir çözümleyici için koşulsuz istisna, eşleştiği her şey için doğrudan bir DNS yoludur, yalnızca uç noktanın adı için değil.
Uç nokta değişikliğini kanıtlayın, ilk bağlantıyı değil
İstemcinin desteklenen yöneticisini kullanın, çözümleme ve engellemeyi zaten koordine ediyorsa. Site tarafından yönetilen bir PF ana bilgisayarında, farklı yaşam döngüsü davranışına sahip başka bir platformdan ana bilgisayar adı tablosu sözdizimini kopyalamak yerine sitenin sahipliğini ve kurtarma planını koruyun.
Onaylanmış, zararsız bir testle, kontrollü bir değişiklikten önce ve sonra istemcinin seçtiği adresi etkin izin verilen kümeyle karşılaştırın. Başarısız bir aramayı, artık geçerli olmayan bir girdinin silinmesini ve destekleniyorsa farklı bir adres ailesini kapsayın. Amaçlanan tünel kurtarılmalı, ilgisiz doğrudan trafik politikada kalmalıdır. Başarılı ilk bağlantı yalnızca ilk çevirinin tesadüfen doğru olduğunu kanıtlar.