Bu makalede Azure NAT ağ geçidi için en iyi yöntemler sağlanmaktadır. Bu kılavuz, mimari mükemmelliğini temel alan beş yapı taşını temel alır: Maliyet İyileştirme, Operasyonel Mükemmellik, Performans Verimliliği, Güvenilirlik ve Güvenlik.
Azure NAT Gateway hakkında çalışan bir bilginiz olduğunu ve ilgili özellikler konusunda bilgi sahibi olduğunuzu varsayıyoruz. Yenileyici olarak Azure NAT Gateway belgelerinin tamamını gözden geçirin.
NAT, ağ adresi çevirisi anlamına gelir. Bkz. Ağ Adresi Çevirisi'ne giriş.
Maliyet iyileştirme
NAT ağ geçidi kullanmaktan kaçınmak için PaaS hizmetlerine erişim Azure Özel Bağlantı veya hizmet uç noktaları (depolama dahil) üzerinden olmalıdır. Özel Bağlantı ve hizmet uç noktaları, PaaS hizmetlerine erişmek için NAT ağ geçidinin çapraz geçişini gerektirmez. Bu yaklaşım, NAT ağ geçidinin maliyetlerini Özel Bağlantı veya hizmet uç noktalarıyla karşılaştırırken işlenen verilerin GB başına ücretini azaltır. Özel Bağlantı veya hizmet uç noktalarını kullanmanın ek güvenlik avantajları vardır.
Performans verimliliği
Her NAT ağ geçidi kaynağı 50 Gb/sn'ye kadar aktarım hızı sağlar. Dağıtımlarınızı birden çok alt ağa bölebilir ve ardından ölçeği genişletmek için her alt ağı veya alt ağ grubunu bir NAT ağ geçidi atayabilirsiniz.
Her NAT ağ geçidi genel IP adresi 64.512 SNAT bağlantı noktası sağlar. NAT ağ geçidine en fazla 16 IP adresi atanabilir. IP adresleri tek tek Standart Genel IP adresleri, Genel IP ön eki veya her ikisi olabilir. Aynı hedef uç noktaya giden bağlantılar için NAT ağ geçidi, atanmış giden IP adresi başına sırasıyla TCP ve UDP için en fazla 50.000 eşzamanlı akışı destekleyebilir. Ayrıntılar için Kaynak Ağ Adresi Çevirisi (SNAT) ile ilgili aşağıdaki bölümü gözden geçirin. TCP, İletim Denetimi Protokolü,UDP ise Kullanıcı Veri Birimi Protokolü anlamına gelir.
SNAT tükenmesi
- NAT ağ geçidi kaynaklarının varsayılan TCP boşta kalma zaman aşımı 4 dakikadır ve bu süre 120 dakikaya kadar yapılandırılabilir. Bu ayar varsayılan değerden daha yüksek bir değere değiştirilirse NAT ağ geçidi akışları daha uzun süre tutar ve SNAT bağlantı noktası envanterinde gereksiz baskıya neden olabilir.
- Ölçeği sınırladığı, performansı azalttığı ve güvenilirliği azalttığı için atomik istekler (bağlantı başına bir istek) kötü bir tasarım seçeneğidir. Bunun yerine, bağlantı sayısını ve ilişkili SNAT bağlantı noktalarını azaltmak için HTTP/S bağlantılarını yeniden kullanın. Bağlan yeniden kullanılması, uygulamanın ölçeklendirilmesine daha iyi olanak sağlar. TLS kullanırken el sıkışmalarının, ek yükün ve şifreleme işlemi maliyetlerinin azalması nedeniyle uygulama performansı artar.
- Etki Alanı Adı Sistemi (DNS) aramaları, istemci DNS çözümleyicilerinin sonucunu önbelleğe almadığında birimdeki birçok ayrı akışa neden olabilir. Akış hacmini azaltmak ve SNAT bağlantı noktası sayısını azaltmak için DNS önbelleğini kullanın. DNS, etki alanı adlarını İnternet'e veya özel ağa bağlı kaynakların IP adreslerine eşleyen adlandırma sistemidir.
- DNS aramaları gibi UDP akışları, boşta kalma zaman aşımı sırasında SNAT bağlantı noktalarını kullanır. UDP boşta kalma zaman aşımı süreölçeri 4 dakikada sabittir ve değiştirilemez.
- Bağlantı biriminizi şekillendirmek için bağlantı havuzlarını kullanın.
- Bir TCP akışını asla sessizce bırakmayın ve akışı temizlemek için TCP zamanlayıcılarına güvenmeyin. TCP'nin bağlantıyı açıkça kapatmasına izin vermezseniz, TCP bağlantısı açık kalır. Ara sistemler ve uç noktalar bu bağlantıyı kullanımda tutar ve bu da SNAT bağlantı noktasını diğer bağlantılar için kullanılamaz hale getirir. Bu anti-desen uygulama hatalarını ve SNAT tükenmesini tetikleyebilir.
- etkileri konusunda uzman bilgisi olmadan işletim sistemi düzeyinde TCP'ye yakın ilgili zamanlayıcı değerlerini değiştirmeyin. TCP yığını kurtarılırken, bağlantının uç noktalarının beklentileri eşleşmediğinde uygulama performansınız olumsuz etkilenebilir. Zamanlayıcı değerlerinin değiştirilmesi genellikle temel alınan tasarım sorununun bir işaretidir. Temel alınan uygulamanın başka anti-desenleri varsa, zamanlayıcı değerleri değiştirilirse SNAT tükenmesi de desteklenebilir.
Hizmetinizin ölçeğini ve güvenilirliğini geliştirmek için aşağıdaki kılavuzu gözden geçirin:
- TCP boşta kalma zaman aşımını azaltarak değerleri düşürmenin etkisini keşfedin. Varsayılan 4 dakikalık boşta kalma zaman aşımı SNAT bağlantı noktası envanterini daha önce boşaltabilir.
- Bağlantı kaynaklarınızı diğer işlemler için boşaltmak için uzun süre çalışan işlemler için zaman uyumsuz yoklama desenlerini göz önünde bulundurun.
- Yeniden kullanılan TCP bağlantıları gibi uzun ömürlü akışlar, ara sistemlerin zaman aşımına uğradıklarından kaçınmak için TCP korumalarını veya uygulama katmanı korumalarını kullanmalıdır. Boşta kalma zaman aşımını yalnızca son çare olarak artırmanız gerekir ve kök nedeni çözmeyebilir. Uzun bir zaman aşımı, zaman aşımı süresi dolduğunda düşük hız hatalarına neden olabilir ve gecikme ve gereksiz hatalara neden olabilir. TCP tutmaları, bağlantıyı her iki taraftan da canlı tutmak için bağlantının bir tarafından etkinleştirilebilir.
- UDP trafiğine sahip uzun ömürlü akışlar için, bağlantıları canlı tutmak için UDP korumalarını etkinleştirebilirsiniz. Bağlantının bir tarafında etkinleştirilen UDP korumalarının bağlantıyı yalnızca bir taraftan etkin tuttuğunu unutmayın. Bir bağlantıyı canlı tutmak için udp korumalarının bir bağlantının her iki tarafında da etkinleştirilmesi gerekir.
- Geçici hata veya hata kurtarma sırasında agresif yeniden denemeleri/ani artışları önlemek için düzgün yeniden deneme desenleri kullanılmalıdır. Atomik bağlantılar olarak adlandırılan bir kötü model, her HTTP işlemi için yeni bir TCP bağlantısı oluşturduğunuzda gerçekleşir. Atomik bağlantılar uygulamanızın iyi ölçeklenmesini engeller ve kaynakları boşa harcar. Her zaman birden çok işlemi aynı bağlantıda işlem hattı haline getirebilirsiniz. Uygulamanız işlem hızı ve kaynak maliyetlerinde avantaj sağlar. Uygulamanız aktarım katmanı şifrelemesi (örneğin TLS) kullandığında, yeni bağlantıların işlenmesiyle ilgili önemli bir maliyet vardır. Daha iyi uygulama desenleri için bkz . Azure Bulut Tasarım Desenleri .
Operasyonel mükemmellik
NAT ağ geçidi Azure Kubernetes Service (AKS) ile kullanılabilse de AKS'nin bir parçası olarak yönetilmiyor. Kapsayıcı Ağ Arabirimi (CNI) alt ağına bir NAT ağ geçidi atarsanız, AKS podlarının NAT ağ geçidi üzerinden çıkış yapmasını etkinleştirirsiniz.
Bölgeler arasında veya bölgeler arasında birden çok NAT ağ geçidi kullanırken, Azure Genel IP ön eklerini veya BYOIP ön eklerini kullanarak giden IP varlığını yönetilebilir durumda tutun. NAT ağ geçidine 16 IP adresten (/28 ön ek boyutu) büyük bir IP ön eki boyutu atanamaz.
SNAT bağlantı noktası kullanımını, işlenen veya bırakılan paketleri ve iletilen veri miktarını izlemek ve uyarı vermek için Azure İzleyici uyarılarını kullanın. NAT ağ geçidi yapılandırılmış alt ağındaki sanal makine örneklerinden giden trafik akışını izlemek için NSG akış günlüklerini kullanın.
Bir alt ağ BIR NAT ağ geçidi ile yapılandırıldığında, NAT ağ geçidi bu alt ağ üzerindeki tüm VM'ler için genel İnternet'e giden diğer tüm bağlantıların yerini alır. NAT ağ geçidi, giden kuralları olan veya olmayan bir yük dengeleyiciden ve doğrudan VM'lere atanan genel IP adreslerinden önceliklidir. Azure bir akışın yönünü izler ve asimetrik yönlendirme gerçekleşmez. Gelen kaynaklı trafik, yük dengeleyici ön uç IP'si gibi doğru şekilde çevrilir ve NAT ağ geçidi üzerinden giden kaynaklı trafikten ayrı olarak çevrilir. Bu ayrım, gelen ve giden hizmetlerin sorunsuz bir şekilde bir arada var olmasını sağlar.
NAT ağ geçidi, sanal ağlar için giden bağlantıyı etkinleştirmek için varsayılan olarak önerilir. NAT ağ geçidi, Azure'daki diğer giden bağlantı tekniklerinden daha verimli ve daha az operasyonel karmaşıktır. NAT ağ geçitleri SNAT bağlantı noktalarını isteğe bağlı olarak ayırır ve SNAT bağlantı noktası yeniden kullanım çakışmalarını önlemek için daha verimli bir algoritma kullanır. Varlığınız için varsayılan giden bağlantıya (bir anti-desen) güvenmeyin. Bunun yerine, bunu NAT ağ geçidi kaynaklarıyla açıkça tanımlayın.
Güvenilirlik
NAT ağ geçidi kaynakları bir kullanılabilirlik alanında yüksek oranda kullanılabilir ve birden çok hata etki alanına yayılır. NAT ağ geçidi, Azure'ın NAT ağ geçidini yerleştirmek için otomatik olarak bir bölge seçtiği "hiçbir bölgeye" dağıtılabilir. NAT ağ geçidi, bir kullanıcı tarafından belirli bir bölgeye de yalıtılabilir.
Her alt ağın yalnızca belirli bir bölgede kaynakları olmadığı sürece kullanılabilirlik alanı yalıtımı sağlanamaz. Bunun yerine, VM'lerin dağıtıldığı kullanılabilirlik alanlarının her biri için bir alt ağ dağıtın, bölgesel VM'leri eşleşen bölgesel NAT ağ geçitleriyle hizalayın ve ayrı bölgesel yığınlar oluşturun. Örneğin, kullanılabilirlik alanı 1'deki bir sanal makine, aynı zamanda yalnızca kullanılabilirlik alanı 1'de bulunan diğer kaynaklara sahip bir alt ağdadır. Nat ağ geçidi, bu alt ağa hizmet vermek için kullanılabilirlik alanı 1'de yapılandırılır. Aşağıdaki diyagrama bakın.
Sanal ağlar ve alt ağlar bir bölgedeki tüm kullanılabilirlik alanlarına yayılmıştır. Bölgesel kaynakları barındırmak için bunları kullanılabilirlik alanlarına bölmeniz gerekmez.
Güvenlik
NAT ağ geçidi ile tek tek sanal makinelerin (veya diğer işlem kaynaklarının) genel IP adreslerine ihtiyacı yoktur ve tamamen özel kalabilir. Genel IP adresi olmayan kaynaklar yine de sanal ağ dışındaki dış kaynaklara ulaşabilir. Giden bağlantı için bitişik ip kümesinin kullanıldığından emin olmak için genel IP ön ekini ilişkilendirebilirsiniz. Hedef güvenlik duvarı kuralları bu tahmin edilebilir IP listesine göre yapılandırılabilir.
Yaygın bir yaklaşım, üçüncü taraf güvenlik duvarları veya ara sunucularla yalnızca giden ağ sanal gereci (NVA) senaryosu tasarlamaktır. Bir NAT ağ geçidi sanal makine ölçek kümesi NVA'lara sahip bir alt ağa dağıtıldığında, bu NVA'lar bir yük dengeleyicinin IP'sinin veya tek bir IP'nin aksine giden bağlantı için NAT ağ geçidi adreslerini kullanır. Bu senaryoya Azure Güvenlik Duvarı uygulamak için bkz. azure Standart Load Balancer ile Azure Güvenlik Duvarı tümleştirme.
Bulut için Microsoft Defender NAT ağ geçidi üzerinden şüpheli giden bağlantıları izleyebilir. Bu, Bulut için Microsoft Defender bir uyarı özelliğidir.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazar:
- Ethan Haslett | Üst Düzey Bulut Çözümü Mimarı
Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.