Azure P2S VPN'de statik IP: istemci adresi neden değişir

Her Azure point-to-site istemcisi kimlik doğrulaması sırasında havuzdan bir adres alır ve bunu yalnızca o bağlantı sürdüğü sürece tutar. Rezervasyon tablosu yok, kullanıcı başına eşleme yok ve „bu kişiye her zaman 172.16.0.10 ver“ anlamına gelen bir ağ geçidi ayarı yok. Tam da bu tek mekanizma, insanların sonradan karşılaştığı iki belirtiyi açıklar: eskiden eşleştiği kullanıcıyla artık eşleşmeyen bir NSG kuralı ve kimsenin bilerek eklemediği bir makineyi sessizce içeri alan bir izin listesi. Kuralı daha akıllı bir IP kuralıyla değiştirmek ikisini de düzeltmez, çünkü kuralın adlandırdığı şey sizin denetlemediğiniz bir takvime göre yeniden atanır.

Havuz kapasitedir, kimlik değil. Eşzamanlı tünellerin benzersiz adresler alması için vardır ve kiralama bittiği anda onları geri dönüştürür. Bu netleştiğinde, faydalı soru „bu istemciyi nasıl sabitlerim“ olmaktan çıkar ve „ağ geçidinin geri dönüştürmeyeceği neye karşı kural yazabilirim“ olur.

İstemci bağlandığında ağ geçidi gerçekte ne yapar

Ağ geçidi yapılandırılmış istemci adres havuzunu tutar ve onu bir kiralama tablosu olarak ele alır. Bağlanırken sıradaki boş adresi, pratikte mevcut olan en düşüğünü alır ve istemci bağlantıyı kesene veya kiralama sona erene kadar onu tünel bağdaştırıcısına atar. Sıra belirler, kimlik değil: sakin bir dönemden sonra ilk yeniden bağlanan kişi, o anda tesadüfen boş olan en düşük adresi alır.

Havuzun boyutu davranışı gizler. Test edenlerin sayısından bir iki adres büyük bir laboratuvar havuzu deterministik görünür, çünkü aynı dizüstü bilgisayar her sabah aynı sırayla yeniden bağlanma eğilimindedir. Üçüncü bir makine ekleyin, havuzun boyutunu değiştirin veya öğle yemeği boyunca bir oturumu bağlı bırakın; desen bozulur. Adres hiçbir zaman kararlı değildi; kararlı olan sıraydı.

point-to-site yapılandırmasındaki her değişiklik kiralama alanını da sıfırlar. Farklı bir kimlik doğrulama türü, yeniden boyutlandırılmış bir havuz, yeni bir havuz aralığı veya yıkılıp yeniden kurulan bir ağ geçidi, istemcileri eski adresleriyle artık eşleşmeyen bir havuza geri gönderir. Bu değişikliğin hiçbir parçası NSG'nize dokunmaz, bu yüzden arıza kendiliğinden olmuş gibi görünür.

Bunun olmasını yaklaşık bir dakikada görebilirsiniz. Bağlanın, istemcinin bağlantı ayrıntılarında tünel adresini not edin, bağlantıyı kesin, ikinci bir makine bağlayın, sonra birinciyi yeniden bağlayın. Geri aldığınız adres ikinci makinenin neyi tuttuğuna bağlıdır ve hiçbir portal ayarı öncekini istendiğinde geri getirmez.

İstemci IP'sine dayalı bir NSG aslında bağlantı sırasına ilişkin bir kuraldır

İnsanların ilk yazdığı kural bariz olandır: yönetim VM'sinin NIC'inde veya alt ağında, kaynak olarak VPN istemcisinin iç adresini kullanan bir gelen kuralı. Kısadır, yazıldığı gün testi geçer ve havuzda birden fazla boş adres olduğu anda başarısız olur.

Bundan iki arıza biçimi doğar ve yalnızca biri hata gibi görünür. Meşru bir kullanıcı reddedilir çünkü kuralın adlandırdığı adresi o anda başka biri tutmaktadır ve bu can sıkıcı bir destek talebi olarak gelir. Ya da istenmeyen bir kullanıcı geçirilir çünkü kuralın hâlâ güvendiği bir adresi miras almıştır ve bu, biri erişimi denetleyene kadar hiçbir şey olarak gelmez.

Kural kirayı izlediği için etkin ilke „ilk bağlanan kişi yönetim erişimi alır“ diye okunur. Bu, niyetin kılığına girmiş bir bağlantı sırası betimlemesidir ve hiçbir kural hijyeni onu niyet ifadesine dönüştürmez.

İstemci kiralaması ile ağ geçidi adresi farklı nesnelerdir

Karışıklığın çoğu tek bir kelimeden gelir. Ağ geçidinin nispeten kararlı bir genel IP'si vardır; istemcilerin havuzdan gelen ve kararlı olmayan özel adresleri vardır. Bölge yedekliliği olmayan bir VPN ağ geçidi için genel IP dinamik olarak atanır, ancak yeniden boyutlandırmayı, sıfırlamayı ve rutin bakımı atlatır — ağ geçidinin kendisi silinip yeniden oluşturulduğunda değişir. Bölge yedekli ve bölgesel ağ geçidi SKU'ları Standard SKU genel IP kullanır ve bu atama statik olmalıdır.

Şirket içi eşin yapılandırmasında ihtiyaç duyduğu kararlılık budur ve tek bir istemcinin tanımlanması hakkında hiçbir şey söylemez. Bir iş ortağı hangi adresi göreceğini sorduğunda yanıt, site-to-site altında ağ geçidinin genel IP'si veya paylaşılan bir NAT aralığıdır — asla bir dizüstü bilgisayarın tünel kiralaması değil.

Grup havuzları size kural yazmaya değer bir aralık verir

Virtual WAN point-to-site kullanıcı gruplarını destekler ve her gruba kendi istemci adres havuzu atanabilir. Üyelik kimlikle belirlenir, bu yüzden istemcinin düştüğü aralık öngörülebilir olur: operasyonlar bir aralıkta, yükleniciler başka bir aralıkta ve aralık, güvenlik duvarı veya NSG kuralının tahmin etmeden adlandırabileceği bir şeydir.

Ortaya çıkan kural kümesinin gözden geçirebileceğiniz bir biçimi vardır:

• her hedef kitle için bir havuz, kişi sayısına değil eşzamanlı oturum zirvesine göre boyutlandırılmış;
• grup üyeliği kimlik üzerinden yönetilir, her katılan olduğunda kurallar düzenlenerek değil;
• NSG veya Azure Firewall kuralları havuz aralıklarına karşı yazılır, asla tek tek kiralamalara karşı değil;
• bir aralığı asla paylaşmaması gereken hedef kitleler için ayrı bir merkez veya ağ geçidi.

Havuzun tamamını izin listesine koymak dürüst ama kabadır: o aralıktaki her bağlı istemci aynı erişimi alır. Bu, bir inceleme sırasında keşfetmek yerine yüksek sesle söylenmeye değer bir politika kararıdır. Hâlâ kişi başına yanıt gerektiren her şey, paket filtresine değil, rol atamaları yoluyla kaynağa aittir.

Dağıtım Virtual WAN'a geçemediğinde

Birçok ağ geçidi sıradan VPN ağ geçidi olarak kalır ve Virtual WAN'a geçmek önemsiz bir değişiklik değildir. Pratik yanıt, kullanıcı başına kararı paket filtresinden, kullanıcının kim olduğunu zaten bilen bir şeye taşımaktır.

Kaynak düzeyinde kimlik en ucuz sürümdür. Storage, SQL ve Key Vault'un tümü, kullanıcı veya grup başına rol atamalarıyla Entra ID kimlik doğrulamasını destekler, bu yüzden VPN'in yalnızca ağ erişilebilirliğini kanıtlaması gerekir. Adlandırılmış hesaplara sahip bir atlama sunucusu, yönetim işi için aynı işi yapar, çünkü sunucu kişiyi kaydeder ve tünel yalnızca paket taşır. İstemcileri DNS'e kaydetmek ve numara yerine ada izin vermek kuralı bir katman yukarı taşır. Uygulama katmanı kimliği — bir sertifika konusu, bir belirteç iddiası, bir grup üyeliği — karar vermesi istenen şey ağ değil uygulama olduğunda çalışır.

Sabit bir kaynak adresinde ısrar eden bir iş ortağı için yanıt, tanımlı bir eş önekiyle site-to-site veya ExpressRoute'tur. Eş önekine izin verirler, kendi taraflarında görünen adres ağ geçidine aittir ve biri dizüstü bilgisayarı yeniden başlattığında değişmez.

Başka bir izin listesini düzenlemeden önce havuzu denetleyin

Havuzun iki özelliği, insanların istemciye yüklediği davranışın çoğuna neden olur. Çok küçük bir havuz kiralamaları hızlı geri dönüştürür, bu yüzden adresler sürekli hareket ediyormuş gibi görünür ve adrese dayalı her kural tasarım gereği güvenilmez görünür. Şirket içi aralıklarla veya sanal ağın adres alanıyla çakışan bir havuz, hiçbir güvenlik duvarı kuralının düzeltemediği bir yönlendirme belirsizliği yaratır.

Bir kurala dokunmadan önce üç şeyi tek bir sayfaya koyun: point-to-site havuzu, sanal ağın adres alanı ve şirket içi aralıklar. Çakışmamalıdırlar ve havuzun her eşzamanlı istemci için yer artı yeniden bağlantılar için bir paya ihtiyacı vardır.

Sonra döngüyü şu sırayla kapatın:

• İki makineden her iki sırayla bağlanın ve adresleri karşılaştırın; yer değiştirebiliyorlarsa adrese dayalı hiçbir kural güvenli değildir.
• Ağ geçidinin Virtual WAN olup olmadığını denetleyin; öyleyse adres başına kural yerine grup havuzlarını kullanın.
• Bir kural yanlış kişiye denk geldiğinde ne olduğunu sorun; yanıt bir erişim olayıysa denetimi kimliğe taşıyın.
• Hangi aralığın hangi gruba ait olduğunu NSG tanımlarıyla aynı depoda kaydedin.
• Havuz, kimlik doğrulama veya ağ geçidi değişikliğinden sonra yeniden test edin, çünkü bu değişiklikler eşlemeyi duyurmadan yeniden yazar.