Przewodnik po usłudze Private Link i systemie DNS w usłudze Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Usługa Azure Private Link umożliwia klientom uzyskiwanie dostępu do usług Platformy jako usługi (PaaS) platformy Azure bezpośrednio z prywatnych sieci wirtualnych bez korzystania z publicznego adresowania IP. Dla każdej usługi należy skonfigurować prywatny punkt końcowy, który używa prywatnego adresu IP z sieci. Klienci mogą następnie używać prywatnego punktu końcowego, aby połączyć się prywatnie z usługą.

Klienci nadal używają w pełni kwalifikowanej nazwy domeny (FQDN) usługi, aby nawiązać z nią połączenie. Należy skonfigurować system DNS w sieci, aby rozpoznać nazwę FQDN usługi na prywatny adres IP prywatnego punktu końcowego.

Twój projekt sieci, a w szczególności konfiguracja DNS, są kluczowymi czynnikami w zakresie obsługi łączności prywatnego punktu końcowego z usługami. Ten artykuł jest jedną z serii artykułów, które zawierają wskazówki dotyczące implementowania różnych scenariuszy usługi Private Link. Nawet jeśli żaden ze scenariuszy nie pasuje dokładnie do Twojej sytuacji, powinien być w stanie dostosować projekty do swoich potrzeb.

Uruchamianie topologii sieci

Topologia sieci początkowej to architektura sieci, która służy jako punkt wyjścia dla wszystkich scenariuszy w tej serii artykułów. Architektura jest typową siecią piasty i szprych, która korzysta z usługi Azure Virtual WAN.

Rysunek 1. Uruchamianie topologii sieci dla wszystkich prywatnych punktów końcowych i scenariuszy DNS

Pobierz plik programu Visio tej architektury. Ta topologia ma następujące cechy:

Jest to sieć piasty i szprych zaimplementowana za pomocą usługi Azure Virtual WAN.
Istnieją dwa regiony— każdy z regionalnym koncentratorem wirtualnym zabezpieczonym za pomocą usługi Azure Firewall.
Każde zabezpieczone regionalne centrum wirtualne ma następujące ustawienia zabezpieczeń dla połączeń usługi Azure Virtual Network:
- Ruch internetowy: zabezpieczony przez usługę Azure Firewall — cały ruch wychodzący do Internetu przepływa przez zaporę centrum regionalnego.
- Ruch prywatny: zabezpieczony przez usługę Azure Firewall — cały ruch przesyłany z szprychy do szprych przepływa przez zaporę koncentratora regionalnego.
Każde regionalne centrum wirtualne jest zabezpieczone za pomocą usługi Azure Firewall. Zapory koncentratora regionalnego mają następujące ustawienia:
- Serwery DNS: domyślne (udostępnione na platformie Azure) — zapora centrum regionalnego jawnie używa usługi Azure DNS do rozpoznawania nazw FQDN w kolekcjach reguł.
- Serwer proxy DNS: włączone — zapora centrum regionalnego odpowiada na zapytania DNS na porcie 53. Przekazuje ona zapytania do usługi Azure DNS w celu uzyskania wartości niecached.
- Zapora rejestruje oceny reguł i żądania serwera proxy DNS do obszaru roboczego usługi Log Analytics, który znajduje się w tym samym regionie. Rejestrowanie tych zdarzeń jest typowym wymaganiem dotyczącym rejestrowania zabezpieczeń sieci.
Każda połączona sieć wirtualna szprycha ma domyślny serwer DNS skonfigurowany jako prywatny adres IP zapory koncentratora regionalnego. W przeciwnym razie ocena reguły nazwy FQDN może nie być zsynchronizowana.

Routing w wielu regionach

Zabezpieczone koncentratory usługi Virtual WAN mają ograniczoną obsługę łączności między koncentratorami, gdy istnieje wiele zabezpieczonych koncentratorów wirtualnych. To ograniczenie dotyczy scenariuszy obejmujących wiele centrów, wewnątrz regionów i między regionami. W związku z tym topologia sieci nie ułatwia bezpośredniego filtrowania prywatnego ruchu między regionami za pośrednictwem usługi Azure Firewall. Obsługa tej funkcji jest dostarczana przy użyciu intencji routingu i zasad routingu koncentratora usługi Virtual WAN. Ta funkcja jest obecnie dostępna w wersji zapoznawczej.

W tej serii artykułów założeniem jest to, że wewnętrzny zabezpieczony ruch nie przechodzi przez wiele koncentratorów. Ruch, który musi przechodzić przez wiele koncentratorów, musi to zrobić w topologii równoległej, która nie filtruje ruchu prywatnego za pośrednictwem zabezpieczonego koncentratora wirtualnego, ale umożliwia mu zamiast tego przejście.

Dodawanie sieci szprych

Podczas dodawania sieci szprych są one zgodne z ograniczeniami zdefiniowanymi w topologii początkowej sieci. W szczególności każda sieć szprych jest skojarzona z domyślną tabelą tras, która znajduje się w jej regionalnym centrum, a zapora jest skonfigurowana do zabezpieczania ruchu internetowego i prywatnego. Poniższy zrzut ekranu przedstawia przykład konfiguracji:

Rysunek 2. Konfiguracja zabezpieczeń połączeń sieci wirtualnej w koncentratonie wirtualnym

Kluczowe wyzwania

Początkowa topologia sieci tworzy wyzwania związane z konfigurowaniem systemu DNS dla prywatnych punktów końcowych.

Chociaż korzystanie z usługi Virtual WAN zapewnia zarządzane środowisko centrum, kompromis polega na tym, że istnieje ograniczona możliwość wpływania na konfigurację koncentratora wirtualnego lub możliwość dodawania do niego większej liczby składników. Tradycyjna topologia piasty i szprych umożliwia izolowanie obciążeń w szprychach przy jednoczesnym udostępnianiu typowych usług sieciowych, takich jak rekordy DNS, w samozarządzanym koncentratonie. Zwykle łączysz prywatną strefę DNS z siecią koncentratora, aby usługa Azure DNS mogła rozpoznawać prywatne adresy IP punktów końcowych dla klientów.

Nie można jednak połączyć prywatnych stref DNS z koncentratorami usługi Virtual WAN, więc rozpoznawanie nazw DNS, które odbywa się w centrum, nie jest świadome stref prywatnych. W szczególności jest to problem dla usługi Azure Firewall, skonfigurowanego dostawcy DNS dla szprych obciążeń, który używa systemu DNS do rozpoznawania nazw FQDN.

W przypadku korzystania z koncentratorów usługi Virtual WAN wydaje się intuicyjne połączenie prywatnych stref DNS z sieciami wirtualnymi szprych, w których obciążenia oczekują rozpoznawania nazw DNS. Jednak zgodnie z opisem w architekturze serwer proxy DNS jest włączony w regionalnych zaporach i oczekuje się, że wszystkie szprychy używają swojej regionalnej zapory jako źródła DNS. Usługa Azure DNS jest wywoływana z zapory zamiast z sieci obciążenia, więc żadne prywatne łącza strefy DNS w sieci obciążenia nie są używane w rozwiązaniu.

Uwaga

Aby skonfigurować regionalną zaporę jako dostawcę dns szprychy, ustaw niestandardowy serwer DNS w sieci wirtualnej będącej szprychą, aby wskazywał prywatny adres IP zapory zamiast na normalną wartość usługi Azure DNS.

Biorąc pod uwagę złożoność, która wynika z włączenia serwera proxy DNS w regionalnych zaporach, przejrzyjmy przyczyny jego włączenia.

Reguły sieciowe usługi Azure Firewall obsługują limity oparte na nazwach FQDN, aby dokładniej kontrolować ruch wychodzący, który nie obsługuje reguł aplikacji. Ta funkcja wymaga włączenia serwera proxy DNS. Typowym zastosowaniem jest ograniczenie ruchu protokołu NTP (Network Time Protocol) do znanych punktów końcowych, takich jak time.windows.com.
Zespoły ds. zabezpieczeń mogą korzystać z rejestrowania żądań DNS. Usługa Azure Firewall ma wbudowaną obsługę rejestrowania żądań DNS, dlatego wymaganie, aby wszystkie zasoby szprych używały usługi Azure Firewall, ponieważ ich dostawca DNS zapewnia szeroki zakres rejestrowania.

Aby zilustrować wyzwania, w poniższych sekcjach opisano dwie konfiguracje. Istnieje prosty przykład, który działa, i bardziej złożony, który nie, ale jego awaria jest pouczająca.

Scenariusz roboczy

Poniższy przykład to podstawowa konfiguracja prywatnego punktu końcowego. Sieć wirtualna zawiera klienta, który wymaga użycia usługi PAAS za pomocą prywatnego punktu końcowego. Prywatna strefa DNS połączona z siecią wirtualną ma rekord A, który rozpoznaje nazwę FQDN usługi na prywatny adres IP prywatnego punktu końcowego. Na poniższym diagramie przedstawiono przepływ.

Rysunek 3. Podstawowa konfiguracja DNS dla prywatnych punktów końcowych

Pobierz plik programu Visio z tą architekturą.

Klient wysyła żądanie stgworkload00.blob.core.windows.net.
Usługa Azure DNS, skonfigurowany serwer DNS dla sieci wirtualnej, jest odpytywane pod kątem adresu IP dla stgworkload00.blob.core.windows.net.

Uruchomienie następującego polecenia z maszyny wirtualnej ilustruje, że maszyna wirtualna jest skonfigurowana do używania usługi Azure DNS (168.63.129.16) jako dostawcy DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
Prywatna strefa privatelink.blob.core.windows.net DNS jest połączona z siecią wirtualną obciążenia, więc usługa Azure DNS dołącza rekordy z sieci wirtualnej obciążenia w odpowiedzi.
Ponieważ rekord A istnieje w prywatnej strefie DNS, która mapuje nazwę FQDN, stgworkload00.privatelink.blob.core.windows.netna prywatny adres IP prywatnego punktu końcowego, zwracany jest prywatny adres IP 10.1.2.4.

Uruchomienie następującego polecenia z maszyny wirtualnej powoduje rozpoznawanie nazwy FQDN konta magazynu na prywatny adres IP prywatnego punktu końcowego.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
Żądanie jest wystawiane na prywatny adres IP prywatnego punktu końcowego, który w tym przypadku to 10.1.2.4.
Żądanie jest kierowane za pośrednictwem usługi Private Link do konta magazynu.

Projekt działa, ponieważ usługa Azure DNS:

Czy skonfigurowany serwer DNS dla sieci wirtualnej.
Jest świadomy połączonej prywatnej strefy DNS.
Rozwiązuje zapytania DNS przy użyciu wartości strefy.

Scenariusz niepracujący

Poniższy przykład to naiwna próba użycia prywatnych punktów końcowych w topologii początkowej sieci. Nie można połączyć prywatnej strefy DNS z koncentratorem usługi Virtual WAN. W związku z tym, gdy klienci są skonfigurowani do używania zapory jako serwera DNS, żądania DNS są przekazywane do usługi Azure DNS z poziomu koncentratora wirtualnego, co nie ma połączonej prywatnej strefy DNS. Usługa Azure DNS nie wie, jak rozpoznać zapytanie inne niż podanie domyślnego adresu IP, czyli publicznego adresu IP.

Rysunek 4. Naiwna próba użycia prywatnych punktów końcowych w topologii początkowej sieci

Pobierz plik programu Visio z tą architekturą.

Klient wysyła żądanie stgworkload00.blob.core.windows.net.

Uruchomienie następującego polecenia z maszyny wirtualnej ilustruje, że maszyna wirtualna jest skonfigurowana do używania zapory koncentratora wirtualnego jako dostawcy DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
Zapora ma włączony serwer proxy DNS z ustawieniem domyślnym do przekazywania żądań do usługi Azure DNS. Żądanie jest przekazywane do usługi Azure DNS.
Usługa Azure DNS nie może rozpoznać stgworkload00.blob.core.windows.net prywatnego adresu IP prywatnego punktu końcowego, ponieważ:
1. Nie można połączyć prywatnej strefy DNS z koncentratorem usługi Virtual WAN.
2. Usługa Azure DNS nie zna prywatnej strefy DNS połączonej z siecią wirtualną obciążenia, ponieważ skonfigurowany serwer DNS dla sieci wirtualnej obciążenia to Azure Firewall. Usługa Azure DNS odpowiada za pomocą publicznego adresu IP konta magazynu.
Uruchomienie następującego polecenia z maszyny wirtualnej powoduje rozpoznawanie nazwy FQDN konta magazynu na publiczny adres IP konta magazynu.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Ponieważ usługa Azure Firewall obsługuje zapytania DNS, możemy je zarejestrować. Poniżej przedstawiono przykładowe dzienniki serwera proxy DNS usługi Azure Firewall.
```
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    
```
Klient nie odbiera prywatnego adresu IP punktu końcowego usługi Private Link i nie może nawiązać połączenia prywatnego z kontem magazynu.

Powyższe zachowanie jest oczekiwane. Problem dotyczy scenariuszy.

Scenariusze

Chociaż rozwiązania tego problemu są podobne, przejście przez typowe scenariusze obciążeń pokazuje, w jaki sposób rozwiązania spełniają wymagania różnych sytuacji. Większość scenariuszy składa się z klienta, który uzyskuje dostęp do co najmniej jednej usługi PaaS za pośrednictwem prywatnego punktu końcowego. Są one zgodne z topologią sieci początkowej, ale różnią się wymaganiami dotyczącymi obciążenia. Scenariusze zaczynają się po prostu z klientem, który uzyskuje dostęp do pojedynczej regionalnej usługi PaaS. Są one coraz bardziej złożone, dodając więcej widoczności sieci, regionów i usług PaaS.

W większości scenariuszy klient jest implementowany jako maszyna wirtualna, a usługa PaaS, do którego uzyskuje dostęp klient, jest kontem magazynu. Należy wziąć pod uwagę maszyny wirtualne jako rezerwowe dla dowolnego zasobu platformy Azure, który ma kartę sieciową uwidacznianą w sieci wirtualnej, na przykład zestawy skalowania maszyn wirtualnych, węzły usługi Azure Kubernetes Service lub dowolną inną usługę, która kieruje się w podobny sposób.

Ważne

Implementacja usługi Private Link dla konta usługi Azure Storage może się różnić od innych usług PaaS w subtelny sposób, ale jest dobrze dopasowana dla wielu. Na przykład niektóre usługi usuwają rekordy FQDN podczas uwidaczniania za pośrednictwem usługi Private Link, co może spowodować różne zachowania, ale takie różnice zwykle nie są czynnikiem w rozwiązaniach dla tych scenariuszy.

Każdy scenariusz rozpoczyna się od żądanego stanu końcowego i szczegóły konfiguracji wymaganej do pobrania z topologii sieci początkowej do żądanego stanu końcowego. Rozwiązanie dla każdego scenariusza korzysta ze wzorca rozszerzeń koncentratora wirtualnego. Ten wzorzec dotyczy sposobu uwidaczniania usług udostępnionych w izolowany i bezpieczny sposób jako rozszerzenie koncepcyjne do regionalnego centrum. Poniższa tabela zawiera linki do wzorca rozszerzenia koncentratora wirtualnego i scenariuszy.

Przewodnik	opis
Pojedynczy region, dedykowana usługa PaaS	Obciążenie w jednym regionie uzyskuje dostęp do jednego dedykowanego zasobu PaaS.

Następne kroki

Zapoznaj się ze scenariuszem pojedynczego regionu dedykowanego zasobu PaaS

Udostępnij za pośrednictwem

Przewodnik po usłudze Private Link i systemie DNS w usłudze Azure Virtual WAN