Birçok müşteri için, sanal ağlarından İnternet’e giden bağlantılar yapmak, Azure çözüm mimarilerinin temel bir gereksinimidir. Güvenlik, esneklik ve ölçeklenebilirlik gibi faktörler, giden bağlantının belirli bir mimari için nasıl çalışacağını tasarlarken göz önünde bulundurulması gereken önemli faktörlerdir. Neyse ki Azure, İnternet’e yüksek oranda kullanılabilir ve güvenli giden bağlantı sağlamak için yalnızca bir çözüme sahiptir: Sanal Ağ NAT. NAT ağ geçidi olarak da bilinen Sanal Ağ NAT, ölçeklendirilmesi kolay, büyük ölçekli ve değişken iş yüklerini işlemek için özel olarak tasarlanmış, tam olarak yönetilen ve yüksek oranda dayanıklı bir hizmettir.

NAT ağ geçidi, bir alt ağa ve genel IP adresine bağlanması yoluyla İnternet’e giden bağlantı sağlar. NAT, ağ adresi çevirisi anlamına gelir ve adından da anlaşılacağı gibi, NAT ağ geçidi bir alt ağla ilişkilendirildiğinde, bir alt ağın kaynaklarının (sanal makineler gibi) tüm özel IP’leri NAT ağ geçidinin genel IP adresine çevrilir. NAT ağ geçidi genel IP adresi daha sonra alt ağın kaynakları için kaynak IP adresi olarak hizmet eder. NAT ağ geçidi, genel IP adreslerinin ve öneklerin herhangi bir birleşiminden toplam 16 IP adresine eklenebilir.

Şekil 1: Alt ağ, genel IP adresi ve önek içeren NAT ağ geçidi yapılandırması.

Müşteri, aynı hedef uç noktaya binlerce bağlantı kurmaya çalışırken bağlantı zaman aşımları nedeniyle durduruluyor

Finans, perakende veya aynı kaynaktan büyük veri kümelerinden yararlanmayı gerektiren diğer senaryolar gibi sektörlerdeki müşterilerin, bu veri kaynağına bağlanmak için güvenilir ve ölçeklenebilir bir yönteme ihtiyacı vardır.

Bu blogda, NAT ağ geçidinden yararlanarak mümkün olan böyle bir örneği inceleyeceğiz.

Müşteri geçmişi

Bir müşteri, birincil iş yüklerinden biri için iş kararları almak, analiz etmek ve nihayetinde iş kararları almak için yüksek miktarda veri toplar. Bu veriler, sahip oldukları bir veri merkezinde barındırılan bir servis sağlayıcının REST API’lerinden internet üzerinden toplanır. Müşterinin ilgilendiği veri kümeleri günlük olarak değişebileceğinden, yinelenen bir rapora güvenilemez, veri kümelerini her gün istemeleri gerekir. Veri hacmi nedeniyle, sonuçlar sayfalandırılır ve parçalar halinde paylaşılır. Bu, müşterinin bu tek iş yükü için her gün on binlerce API isteğinde bulunması gerektiği anlamına gelir ve bu genellikle bir ila iki saat sürer. Her istek, önceki şirket içi kurulumlarına benzer şekilde kendi ayrı HTTP bağlantısıyla ilişkilidir.

Başlangıç mimarisi

Bu senaryoda, müşteri Azure sanal ağından hizmet sağlayıcısının şirket içi ağındaki REST API ‘Lere bağlanır. Hizmet sağlayıcısının şirket içi ağı bir güvenlik duvarının arkasında bulunur. Müşteri, bazen bir veya daha fazla sanal makinenin REST API uç noktasından gelen yanıtlar için uzun süre beklediğini fark etmeye başladı. Yanıt bekleyen bu bağlantılar sonunda zaman aşımına uğrayacak ve bağlantı hatalarına neden olacaktır.

Şekil 2: Müşteri, trafiği Azure sanal ağındaki sanal makine ölçek kümesinden (VMSS) internet üzerinden bir güvenlik duvarının önünü açtığı şirket içi hizmet sağlayıcısının veri merkezi sunucusuna (REST API) gönderir.

Soruşturma

Paket yakalamalarla ilgili daha derin bir inceleme sonucunda, hizmet sağlayıcının güvenlik duvarının Azure ağlarından gelen bağlantıları sessizce bıraktığı tespit edildi. Müşterinin Azure’daki mimarisi, ihtiyaç duydukları verileri toplamak için hizmet sağlayıcısının REST API’lerine giden bağlantı hacmini işlemek üzere özel olarak tasarlandığından ve ölçeklendirildiğinden, bu durum şaşırtıcı görünüyordu. Peki, soruna tam olarak ne sebep oluyordu?

Müşteri, hizmet sağlayıcısı ve Microsoft destek mühendisleri, Azure ağından gelen bağlantıların neden ara sıra kesildiğini toplu olarak araştırdı ve önemli bir keşif yaptı. Yalnızca bir kaynak bağlantı noktasından ve IP adresinden gelen ve son kullanılan bağlantılar (20 saniye sırasıyla) servis sağlayıcının güvenlik duvarı tarafından kesildi. Bunun nedeni, servis sağlayıcının güvenlik duvarının aynı kaynak IP ve bağlantı noktasından gelen yeni bağlantılarda 20 saniyelik bir bekleme süresi zorlamasıdır. Aynı genel IP üzerinde yeni bir kaynak bağlantı noktası kullanan bağlantılar, güvenlik duvarının bekleme süresi zamanlayıcısından etkilenmedi. Bu bulgulardan, müşterinin Azure sanal ağından kaynak ağ adresi çevirisi (SNAT) bağlantı noktalarının, hizmet sağlayıcısının REST API ‘sine yeni bağlantılar yapmak için çok hızlı bir şekilde yeniden kullanıldığı sonucuna varılmıştır. Bekleme süresi sayacı tamamlanmadan önce bağlantı noktaları yeniden kullanıldığında, bağlantı zaman aşımına uğrayacak ve sonuçta başarısız olacaktı. Müşteri daha sonra şu soruyla karşı karşıya kaldı: Bağlantı noktalarının servis sağlayıcının REST API’sine bağlantı kurmak için çok hızlı bir şekilde yeniden kullanılmasını nasıl önleyebiliriz? Güvenlik duvarının bekleme zamanlayıcısı değiştirilemediğinden, müşteri kendi kısıtlamaları dahilinde çalışmak zorunda kaldı.

Kurtarmaya giden NAT ağ geçidi

Bu verilere dayanarak, NAT ağ geçidi müşterinin Azure’daki kurulumuna kavram kanıtı olarak eklenmiştir. Bu değişiklikle, bağlantı zaman aşımı sorunları geçmişte kaldı.

NAT ağ geçidi, bu müşterinin giden bağlantı sorununu iki nedenden dolayı hizmet sağlayıcısının REST API’lerine çözebildi. Birincisi, NAT ağ geçidi bağlantı noktalarını büyük bir bağlantı noktası envanterinden rasgele seçer. Yeni bir bağlantı kurmak için seçilen kaynak bağlantı noktasının yeni olma olasılığı yüksektir ve bu nedenle güvenlik duvarından sorunsuz bir şekilde geçecektir. NAT ağ geçidi için kullanılabilen bu büyük bağlantı noktası envanteri, ona bağlı genel IP’lerden türetilir. NAT ağ geçidine bağlı her genel IP adresi, bir alt ağın kaynaklarına 64.512 SNAT bağlantı noktası sağlar ve NAT ağ geçidine en fazla 16 genel IP adresi eklenebilir. Bu, bir müşterinin giden bağlantılar yapmak için bir alt ağda kullanabileceği 1 milyondan fazla SNAT bağlantı noktasına sahip olabileceği anlamına gelir. İkinci olarak, NAT ağ geçidi tarafından servis sağlayıcının REST API’lerine bağlanmak için yeniden kullanılan kaynak bağlantı noktaları, güvenlik duvarının 20 saniyelik bekleme süresi zamanlayıcısından etkilenmez. Bunun nedeni, kaynak bağlantı noktalarının NAT ağ geçidi tarafından en azından yeniden kullanılmadan önce güvenlik duvarının bekleme süresi zamanlayıcısı kadar uzun süre kendi bekleme süresi içinde ayarlanmasıdır. Daha fazla bilgi edinmek için NAT ağ geçidi SNAT bağlantı noktası yeniden kullanım zamanlayıcıları hakkındaki genel makalemize bakın.

NAT ağ geçidinin SNAT bağlantı noktasını yeniden kullanma davranışı aracılığıyla değil, aynı zamanda SNAT bağlantı noktalarını bir alt ağın kaynakları arasında dinamik olarak nasıl ayırdığı aracılığıyla SNAT bağlantı noktası tükenmesini nasıl çözdüğüne dair ayrıntılı bir inceleme yapacağımız bir sonraki blogumuz için bizi izlemeye devam edin.

Daha fazla bilgi edinin

Yukarıdaki müşteri senaryosu aracılığıyla, NAT ağ geçidinin SNAT bağlantı noktalarını seçmesinin ve yeniden kullanmasının, Azure’un giden giden bağlantı için neden önerilen seçenek olduğunu nasıl kanıtladığını öğrendik. NAT ağ geçidi yalnızca SNAT bağlantı noktasının tükenmesi riskini azaltmakla kalmaz, aynı zamanda rastgele bağlantı noktası seçimi aracılığıyla bağlantı zaman aşımlarını da azaltabildiğinden, NAT ağ geçidi Azure ağınızdan İnternet’e giden bağlantı kurarken sonuçta en iyi seçenek olarak hizmet eder.