Microsoft AZ-700: Hibrit Ağ — Çalışma kılavuzu

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft Azure Network Engineer AZ-700 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Hibrit bağlantı temelleri ve adresleme kısıtlamaları

Hibrit bağlantı, şirket içi ve Azure sanal ağları arasında güvenilir, yönlendirilebilir ve güvenli IP erişilebilirliği sağlamakla ilgilidir. Sanal ağ adreslemesini planlarken, bir alt ağ içindeki bazı Azure tarafından yönetilen kaynakların bitişik, çakışmayan adres tahsisi ve bazen de özel olarak ayrılmış adresler gerektirdiğini unutmayın: Azure yük dengeleyiciler ve ağ geçidi alt ağları kasıtlı olarak ayrılmalıdır (GatewaySubnet tam olarak bu şekilde adlandırılmalı ve ağ geçidi SKU ölçeğini karşılayacak şekilde boyutlandırılmalıdır) ve özel uç noktalar ile Azure tarafından yönetilen hizmet uç noktaları, barındıran VNet’ten alınan adreslere ihtiyaç duyar. Şirket içi ve Azure ön eklerinin çakışması en yaygın tuzaktır: çakışan aralıklar yönlendirmeyi ve BGP rota seçimini bozar, asimetrik yönlendirme yaratır ve güvenlik duvarı ilkelerini karmaşıklaştırır. Durum bilgisi olan güvenlik duvarlarını, yük dengeleyicileri veya çok sayıda özel uç noktayı barındıran alt ağlar için en az /27–/24 segmentleri kullanın; özel bir GatewaySubnet ayırın (SKU’ya bağlı olarak /27 veya daha büyük). DNS de aynı derecede kritiktir: özel uç noktalar, platformun özel DNS bölgelerini (örneğin, privatelink.database.windows.net) kullandığından, Azure özel adlarını çözümlemek için şirket içinde koşullu ileticilere veya Azure DNS Private Resolver’a ihtiyaç duyulur. Tasarım ödünleşimleri, IP kullanımı ve esneklik arasındaki dengeye odaklanır: daha yoğun IPv4 şemaları adres alanından tasarruf sağlar ancak çakışma ve geçiş riskini artırırken, daha büyük ve daha az verimli ön ekler gelecekteki genişlemeyi ve BGP duyuru stratejilerini basitleştirir.

VPN Gateway SKU’ları, BGP temelleri ve Local Network Gateway’ler

Doğru VPN ağ geçidi SKU’sunu (VpnGw1–VpnGw5, eski sistemler için Basic) seçmek; aktarım hızını, eş zamanlı S2S/P2S oturum sayısını ve active-active veya rota limitleri gibi mevcut özellikleri doğrudan etkiler. Modern hibrit tasarımlar için rota tabanlı ağ geçitleri kullanın; ilke tabanlı olanlar eskidir ve BGP’yi sınırlar. BGP, ön eklerin dinamik olarak değişimini sağlar ve yol esnekliğini, otomatik yük devretmeyi ve ön ek önceliklendirmeyi destekler — Azure VPN Gateway ASN’sini (varsayılan 65515) yapılandırın ve Local Network Gateway nesnesindeki şirket içi ASN ile eşleştirin veya eş bağlantı kurun. Local Network Gateway; şirket içi genel IP’yi, adres alanını/alanlarını ve isteğe bağlı BGP eş IP’si ile ASN’yi depolar; BGP eş IP’sini girmeyi unutmak veya ASN’lerin eşleşmemesi, rota yayılımını engeller ve statik rota geçici çözümlerine yol açar. Çoklu site ölçeklenebilirliği ve yerleşik transit yönlendirme için Azure Virtual WAN hub’larını değerlendirin; VWAN hub’ları, yüksek ölçekli S2S ve P2S’i destekler ve Azure Firewall ile ExpressRoute ile entegre olur. Rota tablosu yayılımına dikkat edin: varsayılan olarak bazı hub-spoke veya sanal cihaz topolojileri otomatik yayılımı engeller; açık UDR’ler veya BGP rota duyuruları gerekebilir. Ödünleşimler: daha yüksek SKU’lar ve VWAN maliyeti artırır ancak yönetim yükünü azaltır ve aktarım hızı ile yönlendirme ölçeğini iyileştirir.

Noktadan Siteye tasarım seçenekleri, istemci desteği ve DNS entegrasyonu

Noktadan Siteye (P2S) seçimleri; istemci uyumluluğunu, kimlik doğrulamasını ve ölçeği belirler. OpenVPN (SSL) en çapraz platformlu olanıdır ve macOS, Linux ve mobil istemciler için önerilir; IKEv2 hafiftir ve macOS yerel istemcileriyle iyi çalışır; SSTP ise yalnızca Windows’a yönelik daha eski senaryolar için bir seçenek olmaya devam etmektedir. Kimlik doğrulama modları arasında Azure Active Directory (kimlik entegrasyonu ve koşullu erişim için önerilir), sertifika tabanlı kimlik doğrulama ve şirket içi MFA veya RADIUS tabanlı çözümler için RADIUS bulunur. VPN Gateway SKU’su, P2S tünel sayısını ve aktarım hızını belirler; orta ila büyük kullanıcı havuzları için VpnGw2/3’ü, yüksek ölçekli veya aktarım hızına duyarlı kullanım için VpnGw4/5’i seçin. Özel uç noktalar ve P2S, DNS aracılığıyla etkileşime girer: P2S istemcilerinin özel uç nokta adlarını (privatelink bölgeleri) çözümlemesine izin vermek için, ya özel DNS bölgelerini VNet’e bağlayın ya da şirket içi veya istemci DNS’inden Azure DNS Private Resolver ve koşullu ileticileri kullanın. Sık karşılaşılan bir tuzak, P2S istemcilerinin normalde ağ geçidi tarafından sağlanan Azure DNS’i yalnızca istemci rotaları ve DNS ayarlarını gönderdiğinde kullandığını unutmaktır; açık DNS soneki ve iletici yapılandırmaları “özel uç nokta çözümlenemiyor” sorunlarını önler. Ölçeklenebilirlik ve maliyeti dengeleyin: sertifika tabanlı kimlik doğrulama düşük maliyetlidir ancak iptal edilmesi daha zordur; Azure AD modern güvenlik kontrolleri sunar ancak lisanslama/karmaşıklık ekler.

Transit yönlendirme, zorunlu tünelleme, denetim ve güvenlik cihazı yerleşimi

Birden çok VNet, şirket içi ortam ve denetim cihazları arasındaki transit geçişi tasarlamak, yönlendirme ve NAT sınırlarının net bir şekilde uygulanmasını gerektirir. Trafiği Azure Firewall veya sanal cihazlar üzerinden geçmeye zorlamak, güvenlik duvarının özel IP’sine işaret eden kullanıcı tanımlı rotalar (UDR’ler) veya denetimi merkezileştirmek için Virtual WAN hub yönlendirmesinin kullanılmasını gerektirir. Tam şeffaf proxy’leme veya TLS denetimine ihtiyacınız varsa, cihazı bu işe özel bir denetim alt ağına yerleştirin ve ağ geçidi alt ağının ve güvenlik duvarı SKU’larının beklenen aktarım hızı için transit geçişi desteklediğinden emin olun. SNAT davranışına ve genel IP SKU’su seçeneklerine dikkat edin: Tahmin edilebilir giden SNAT ve güvenlik kuralları için Standart Genel IP’ler ve NAT Gateway önerilir; bir dizi Standart genel IP ile eşleştirilmiş bir NAT Gateway, SNAT yükünü hafifletir ve VM başına genel IP yayılmasını önler. Karşılaşılabilecek bir tuzak, şirket içi rotaların ve Azure UDR’lerinin dönüş trafiğinin hedeflenen cihazı atlamasına neden olduğu asimetrik yönlendirmedir; tüm spoke’ların gerekli ön ekleri BGP aracılığıyla duyurduğundan veya trafiği denetim noktasına yönlendiren UDR’lere sahip olduğundan emin olun. Performans ve maliyet karşılaştırması: Azure Firewall Premium veya üçüncü parti yüksek aktarım hızlı cihazlarla donatılmış bir hub-and-spoke mimarisi, korumayı ve merkezi yönetimi artırır ancak aktif-aktif yedekli hub’lar dağıtıp bölgeler arası ağ geçitlerini eşleştirmediğiniz sürece maliyeti ve tek bir hub’da yaşanacak arıza riskini yükseltir.

Pratik Problem: Kullanım Senaryosu

Senaryo: Contoso Ltd.’nin iki şirket içi veri merkezi (Seattle ve Amsterdam) ve tek bir hub VNet’i (VNet-Hub) içinde üç VNet’e (VNet-Prod, VNet-Shared, VNet-Dev) sahip mevcut bir Azure ortamı bulunmaktadır. Şu anda Seattle için bir VpnGw1 VPN Gateway ve Amsterdam için bir Azure Virtual WAN hub’ına siteden siteye bağlantı kullanıyorlar. VNet-Shared içindeki Azure SQL için özel uç noktalar kullanılmaktadır.

Zorluk: Contoso’nun her iki veri merkezi ile Azure arasında dinamik yönlendirmeye (BGP) sahip, dayanıklı ve ölçeklenebilir bir hibrit bağlantıya, macOS kullanıcıları için güvenilir P2S desteğine, şirket içinden özel uç noktaların DNS çözümlemesine ve spoke’lardan gelen giden trafiğin Azure Firewall üzerinden merkezi olarak denetlenmesine ihtiyacı var.

Önerilen Yaklaşım:

1. VNet-Hub içinde, BGP etkinleştirilmiş (ağ geçidi ASN’sini açıkça ayarlayarak) aktif-aktif olarak yapılandırılmış yeni bir VpnGw3 rota tabanlı VPN Gateway dağıtın ve Yerel Ağ Geçidi nesnelerini şirket içi BGP eş IP’leri ve ASN’leri ile güncelleyin; daha yüksek aktarım hızını ve rota limitlerini desteklemek için Seattle S2S bağlantısını yeni ağ geçidine taşıyın.
2. ExpressRoute kurarak veya VWAN hub’ını VNet-Hub ile hub eşlemesine geçirerek Amsterdam bağlantısını hub’da konsolide edin; statik rotalardan kaçınmak ve otomatik yük devretmeyi etkinleştirmek için her iki veri merkezi arasında BGP rota değişimini sağlayın.
3. macOS istemcilerini desteklemek için VpnGw3 üzerinde Azure AD kimlik doğrulaması ile OpenVPN protokolünü kullanarak P2S’i yapılandırın (IKEv2’yi yedek olarak kullanarak) ve istemci havuzlarını VpnGw3 limitlerine göre boyutlandırın; şirket içi DNS üzerinde, privatelink.* bölgelerini, özel uç noktalar için özel DNS bölgelerine bağlanmış olan VNet-Shared içinde dağıtılan bir Azure DNS Private Resolver’a yönlendirmek için bir koşullu iletici yayımlayın.
4. VNet-Hub içinde Azure Firewall’u (TLS denetimi gerekiyorsa Standart veya Premium) aktif-aktif yapılandırmada dağıtın ve spoke alt ağları için 0.0.0.0/0 trafiğini Güvenlik Duvarı’nın özel IP’sine yönlendiren UDR’ler oluşturun; güvenlik duvarına Standart genel IP’lere sahip bir NAT Gateway takın veya açık SNAT ve merkezi Log Analytics’e günlük kaydı için Güvenlik Duvarı’nın genel IP’sini kullanın.

Gerekçe: BGP ile VpnGw3 kullanmak, çoklu site dayanıklılığı için dinamik rota yayılımı ve aktarım hızı sağlar; OpenVPN+Azure AD, macOS kullanıcılarını güvenli bir şekilde destekler; Azure DNS Private Resolver’a DNS yönlendirmesi, şirket içinden özel uç nokta ad çözümlemesini garanti eder; denetimi UDR’ler ile bir Azure Firewall hub’ında merkezileştirmek, asimetrik yönlendirmeyi önler ve ilke yönetimini basitleştirirken, merkezi güvenlik ve gözlemlenebilirlik için maliyetten ödün vermeyi gerektirir.

← Azure Virtual Network Tasarımı · Tüm alanlar · Azure DNS ve Ad Çözümlemesi →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Microsoft'a göz atın →