Azure Özel Bağlantı, istemcilerin genel IP adresi kullanmadan doğrudan özel sanal ağlardan Azure hizmet olarak platform (PaaS) hizmetlerine erişmesini mümkün kılar. Her hizmet için, ağınızdan bir özel IP adresi kullanan özel bir uç nokta yapılandırabilirsiniz. İstemciler daha sonra hizmete özel olarak bağlanmak için özel uç noktayı kullanabilir.
İstemciler, bir hizmete bağlanmak için hizmetin tam etki alanı adını (FQDN) kullanmaya devam eder. Ağınızdaki DNS'yi, hizmetin FQDN'sini özel uç noktanın özel IP adresine çözümlemek için yapılandırabilirsiniz.
Ağ tasarımınız ve özellikle DNS yapılandırmanız, hizmetlere özel uç nokta bağlantısını desteklemede önemli faktörlerdir. Bu makale, çeşitli Özel Bağlantı senaryoları uygulama konusunda rehberlik sağlayan bir dizi makaleden biridir. Senaryolardan hiçbiri sizin durumunuzla tam olarak eşleşmese bile, tasarımları ihtiyaçlarınızı karşılayacak şekilde uyarlayabilmelisiniz.
Ağ topolojisi başlatılıyor
Başlangıç ağ topolojisi , bu makale serisindeki tüm senaryolar için başlangıç noktası olarak hizmet veren bir ağ mimarisidir. Mimari, Azure Sanal WAN kullanan tipik bir merkez-uç ağıdır.
Şekil 1: Tüm özel uç nokta ve DNS senaryoları için ağ topolojisini başlatma
Bu mimarinin Visio dosyasını indirin. Bu topoloji aşağıdaki özelliklere sahiptir:
- Azure Sanal WAN ile uygulanan bir merkez-uç ağıdır.
- Her birinin bölgesel Azure Güvenlik Duvarı güvenli sanal hub'ı olan iki bölge vardır.
- Her güvenli bölgesel sanal merkez, Azure Sanal Ağ bağlantıları için aşağıdaki güvenlik ayarlarına sahiptir:
- İnternet trafiği: Azure Güvenlik Duvarı tarafından güvenli hale getirildi - Bölgesel merkez güvenlik duvarı üzerinden İnternet akışlarına giden tüm trafik.
- Özel trafik: Azure Güvenlik Duvarı ile güvenli hale getirildi - Uçtan uca geçen tüm trafik bölgesel merkez güvenlik duvarı üzerinden akar.
- Her bölgesel sanal merkez Azure Güvenlik Duvarı ile güvenli hale getirilir. Bölgesel merkez güvenlik duvarları aşağıdaki ayarlara sahiptir:
- DNS Sunucuları: Varsayılan (Sağlanan Azure) - Bölgesel merkez güvenlik duvarı, kural koleksiyonlarında FQDN çözümlemesi için Azure DNS'yi açıkça kullanır.
- DNS Ara Sunucusu: Etkin - Bölgesel merkez güvenlik duvarı, 53 numaralı bağlantı noktasındaKI DNS sorgularına yanıt verir. Eşleşmeyen değerler için sorguları Azure DNS'ye iletir.
- Güvenlik duvarı, kural değerlendirmelerini ve DNS proxy isteklerini aynı bölgedeki bir Log Analytics çalışma alanına kaydeder. Bu olayların günlüğe kaydedilmesi yaygın bir ağ güvenlik günlüğü gereksinimidir.
- Her bağlı sanal ağ uçlarının, bölgesel merkez güvenlik duvarının özel IP adresi olacak şekilde yapılandırılmış varsayılan DNS sunucusu vardır. Aksi takdirde FQDN kuralı değerlendirmesi eşitlenmemiş olabilir.
Çok bölgeli yönlendirme
Güvenli Sanal WAN hub'ları, birden çok güvenli sanal hub olduğunda merkezler arası bağlantı için sınırlı desteğe sahiptir. Bu sınırlama çok merkezli, bölge içi ve bölgeler arası senaryoları etkiler. Bu nedenle ağ topolojisi, Azure Güvenlik Duvarı aracılığıyla özel, bölgeler arası trafiğin filtrelenmesine doğrudan olanak sağlamaz. Bu özellik için destek, Sanal WAN hub yönlendirme amacı ve yönlendirme ilkeleri kullanılarak sunulur. Bu özellik şu anda önizleme aşamasındadır.
Bu makale serisinde, iç güvenli trafiğin birden çok hub'dan geçmediği varsayımı yer alır. Birden çok hub'dan geçmesi gereken trafik, güvenli bir sanal hub üzerinden özel trafiği filtrelemeyen ancak bunun yerine geçmesine izin veren paralel bir topoloji üzerinde bunu yapmalıdır.
Uç ağları ekleme
Uç ağları eklediğinizde, bunlar başlangıç ağ topolojisinde tanımlanan kısıtlamaları izler. Özellikle, her uç ağı kendi bölgesel hub'ında bulunan varsayılan yol tablosuyla ilişkilendirilir ve güvenlik duvarı hem İnternet hem de özel trafiğin güvenliğini sağlamak için yapılandırılır. Aşağıdaki ekran görüntüsünde bir yapılandırma örneği gösterilmektedir:
Şekil 2: Sanal hub'daki sanal ağ bağlantıları için güvenlik yapılandırması
Önemli zorluklar
Başlangıç ağ topolojisi, özel uç noktalar için DNS'yi yapılandırmak için zorluklar oluşturur.
Sanal WAN kullanımı size yönetilen bir hub deneyimi sağlarken, bunun dezavantajı sanal hub'ın yapılandırmasını etkileme veya buna daha fazla bileşen ekleme olanağının sınırlı olmasıdır. Geleneksel merkez-uç topolojisi, dns kayıtları gibi ortak ağ hizmetlerini kendi kendine yönetilen hub'da paylaşırken uçlardaki iş yüklerini yalıtmanıza olanak tanır. Azure DNS'nin istemciler için özel uç nokta IP adreslerini çözümleyebilmesi için genellikle özel DNS bölgesini merkez ağına bağlarsınız.
Ancak, özel DNS bölgelerini Sanal WAN hub'lara bağlamak mümkün olmadığından, hub'da gerçekleşen dns çözümlemeleri özel bölgelerin farkında değildir. Bu, FQDN çözümlemesi için DNS kullanan iş yükü uçları için yapılandırılmış DNS sağlayıcısı Azure Güvenlik Duvarı için bir sorundur.
Sanal WAN hub'ları kullandığınızda, özel DNS bölgelerini iş yüklerinin DNS çözümlemesini beklediği uç sanal ağlarına bağlamanız sezgisel görünür. Ancak, mimaride belirtildiği gibi, DNS proxy'si bölgesel güvenlik duvarlarında etkinleştirilir ve tüm uçların DNS kaynağı olarak bölgesel güvenlik duvarlarını kullanması beklenir. Azure DNS, iş yükünün ağı yerine güvenlik duvarından çağrılır, bu nedenle iş yükü ağındaki özel DNS bölgesi bağlantıları çözümde kullanılmaz.
Not
Bölgesel güvenlik duvarını uçun dns sağlayıcısı olacak şekilde yapılandırmak için uç sanal ağında özel DNS sunucusunu normal Azure DNS değeri yerine güvenlik duvarının özel IP'sine işaret eder şekilde ayarlayın.
Bölgesel güvenlik duvarlarında DNS proxy'sini etkinleştirmenin karmaşıklığı göz önünde bulundurulduğunda, etkinleştirmenin nedenlerini gözden geçirelim.
- Azure Güvenlik Duvarı ağ kuralları, uygulama kurallarının işlemediğini çıkış trafiğini daha hassas bir şekilde denetlemek için FQDN tabanlı sınırları destekler. Bu özellik, DNS proxy'lerinin etkinleştirilmesi gerekir. Yaygın bir kullanım, Ağ Süresi Protokolü (NTP) trafiğini gibi
time.windows.combilinen uç noktalarla sınırlamaktır. - Güvenlik ekipleri DNS isteği günlüğünden yararlanabilir. Azure Güvenlik Duvarı, DNS isteği günlüğü için yerleşik desteğe sahiptir, bu nedenle dns sağlayıcıları geniş kapsamlı günlüğe kaydetme kapsamı sağladığı için tüm uç kaynaklarının Azure Güvenlik Duvarı kullanmasını zorunlu tutma.
Zorlukları göstermek için aşağıdaki bölümlerde iki yapılandırma açıklanmaktadır. İşe yarayan basit bir örnek ve işe yarayan daha karmaşık bir örnek vardır, ancak başarısızlığı öğreticidir.
Çalışma senaryosu
Aşağıdaki örnek, temel bir özel uç nokta yapılandırmasıdır. Sanal ağ, özel uç nokta aracılığıyla PAAS hizmetinin kullanılmasını gerektiren bir istemci içerir. Sanal ağa bağlı bir özel DNS bölgesi, hizmetin FQDN'sini özel uç noktanın özel IP adresine çözümleyen bir A kaydına sahiptir. Aşağıdaki diyagramda akış gösterilmektedir.
Şekil 3: Özel uç noktalar için temel DNS yapılandırması
Bu mimarinin bir Visio dosyasını indirin.
İstemci, stgworkload00.blob.core.windows.net için bir istekte bulunur.
Sanal ağ için yapılandırılmış DNS sunucusu olan Azure DNS, stgworkload00.blob.core.windows.net IP adresi için sorgulanır.
Sanal makineden (VM) aşağıdaki komutu çalıştırmak, VM'nin DNS sağlayıcısı olarak Azure DNS (168.63.129.16) kullanacak şekilde yapılandırıldığını gösterir.
resolvectl status eth0 Link 2 (eth0) Current Scopes: DNS Current DNS Server: 168.63.129.16 DNS Servers: 168.63.129.16Özel DNS bölgesi
privatelink.blob.core.windows.netİş Yükü sanal ağından bağlanır, bu nedenle Azure DNS yanıtında İş Yükü sanal ağından kayıtları birleştirir.Özel DNS bölgesinde FQDN,
stgworkload00.privatelink.blob.core.windows.netile özel uç noktanın özel IP'sini eşleyen bir A kaydı bulunduğundan, özel IP adresi 10.1.2.4 döndürülür.VM'den aşağıdaki komutu çalıştırmak, depolama hesabının FQDN'sini özel uç noktanın özel IP adresine çözümler.
resolvectl query stgworkload00.blob.core.windows.net stgworkload00.blob.core.windows.net: 10.1.2.4 -- link: eth0 (stgworkload00.privatelink.blob.core.windows.net)İstek, bu durumda 10.1.2.4 olan özel uç noktanın özel IP adresine verilir.
İstek, Özel Bağlantı üzerinden depolama hesabına yönlendirilir.
Tasarım çalışır çünkü Azure DNS:
- Sanal ağ için yapılandırılmış DNS sunucusudur.
- Bağlı özel DNS bölgesinin farkındadır.
- Bölge değerlerini kullanarak DNS sorgularını çözümler.
Çalışma dışı senaryo
Aşağıdaki örnek, başlangıç ağ topolojisinde özel uç noktaları kullanmaya yönelik basit bir girişimdir. Özel DNS bölgesini bir Sanal WAN hub'ına bağlamak mümkün değildir. Bu nedenle, istemciler güvenlik duvarını DNS sunucusu olarak kullanacak şekilde yapılandırıldığında, DNS istekleri bağlı özel DNS bölgesi olmayan sanal hub'ın içinden Azure DNS'ye iletilir. Azure DNS, genel IP adresi olan varsayılan değeri sağlama dışında sorgunun nasıl çözümleneceğini bilmez.
Şekil 4: Başlangıç ağ topolojisinde özel uç noktaları kullanmaya yönelik basit bir girişim
Bu mimarinin bir Visio dosyasını indirin.
İstemci, stgworkload00.blob.core.windows.net için bir istekte bulunur.
VM'den aşağıdaki komutu çalıştırmak, VM'nin DNS sağlayıcısı olarak sanal hub güvenlik duvarını kullanacak şekilde yapılandırıldığını gösterir.
resolvectl status eth0 Link 2 (eth0) Current Scopes: DNS Current DNS Server: 10.100.0.132 DNS Servers: 10.100.0.132Güvenlik duvarında, istekleri Azure DNS'ye iletmek için varsayılan ayara sahip DNS Ara Sunucusu etkindir. İstek Azure DNS'ye iletilir.
Azure DNS, özel uç noktanın özel IP adresine çözümlenemiyor
stgworkload00.blob.core.windows.netçünkü:- Özel DNS bölgesi bir Sanal WAN hub'ına bağlanamaz.
- İş yükü sanal ağı için yapılandırılmış DNS sunucusu Azure Güvenlik Duvarı olduğundan Azure DNS, iş yükü sanal ağına bağlı özel bir DNS bölgesini tanımaz. Azure DNS, depolama hesabının genel IP adresiyle yanıt verir.
VM'den aşağıdaki komutu çalıştırmak, depolama hesabının FQDN'sini depolama hesabının genel IP'sine çözümler.
resolvectl query stgworkload00.blob.core.windows.net stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0 (blob.bn9prdstr08a.store.core.windows.net)Azure Güvenlik Duvarı DNS sorgularına ara sunucu sağladığından bunları günlüğe kaydedebiliriz. Aşağıda örnek Azure Güvenlik Duvarı DNS Proxy günlükleri verilmişdir.
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113sİstemci, Özel Bağlantı uç noktası için özel IP adresini almaz ve depolama hesabıyla özel bağlantı kuramaz.
Yukarıdaki davranış beklenir. Senaryoların ele alınması gereken sorundur.
Senaryolar
Bu soruna yönelik çözümler benzer olsa da, yaygın iş yükü senaryolarında ilerletmek çözümlerin çeşitli durumların gereksinimlerini nasıl ele alınıyor olduğunu gösterir. Çoğu senaryo, özel uç nokta üzerinden bir veya daha fazla PaaS hizmetine erişen bir istemciden oluşur. Bunlar, başlangıç ağ topolojisine uyar, ancak iş yükü gereksinimlerine göre farklılık gösterir. Senaryolar, tek bir bölgesel PaaS hizmetine erişen bir istemciyle başlar. Bunlar artımlı olarak daha karmaşık hale gelip daha fazla ağ görünürlüğü, bölge ve PaaS hizmeti ekler.
Çoğu senaryoda, istemci bir VM olarak uygulanır ve istemcinin eriştiği PaaS hizmeti bir depolama hesabıdır. VM'leri Sanal Makine Ölçek Kümeleri, Azure Kubernetes Service düğümleri veya benzer şekilde yönlendirilen diğer hizmetler gibi sanal ağda kullanıma sunulan bir NIC'ye sahip herhangi bir Azure kaynağı için bir stand-in olarak düşünmelisiniz.
Önemli
Azure Depolama hesabı için Özel Bağlantı uygulaması, diğer PaaS hizmetlerinden küçük yollarla farklı olabilir, ancak çoğu için iyi uyum sağlar. Örneğin, bazı hizmetler Özel Bağlantı aracılığıyla kullanıma sunulurken FQDN kayıtlarını kaldırır ve bu da farklı davranışlara neden olabilir, ancak bu tür farklılıklar genellikle bu senaryoların çözümlerinde bir faktör değildir.
Her senaryo istenen bitiş durumuyla başlar ve başlangıç ağ topolojisinden istenen bitiş durumuna ulaşmak için gereken yapılandırmayı ayrıntılı olarak açıklar. Her senaryonun çözümü, sanal hub uzantıları deseninin avantajlarından yararlanır. Bu düzen, paylaşılan hizmetlerin bölgesel bir hub'a kavramsal bir uzantı olarak yalıtılmış ve güvenli bir şekilde nasıl kullanıma sunılmasını ele alır. Aşağıdaki tabloda sanal hub uzantısı desenine ve senaryolara bağlantılar yer alır.
| Kılavuz | Açıklama |
|---|---|
| Tek bölge, ayrılmış PaaS | Tek bir bölgedeki iş yükü tek bir ayrılmış PaaS kaynağına erişir. |
Sonraki adımlar
İlgili kaynaklar
- Özel uç nokta nedir?
- Azure Özel Uç Nokta DNS yapılandırması
- Büyük ölçekte Özel Bağlantı ve DNS tümleştirmesi
- Merkez-uç ağında Azure Özel Bağlantı
- Şirket içi ve Azure kaynakları için DNS
- Tek bölgeli veri giriş bölgesi bağlantısı
- Ağları Azure İzleyici'ye bağlamak için Azure Özel Bağlantı'yı kullanma
- Azure DNS Private Resolver
- Şirket içi ağdan çok kiracılı web uygulamalarına gelişmiş güvenlik erişimi
- Temel yüksek oranda kullanılabilir alanlar arası yedekli web uygulaması
- Öğretici: Şirket içi iş yükü için Azure Özel Çözümleyici ile özel uç nokta DNS altyapısı oluşturma