Scenariusz z pojedynczym regionem — usługa Private Link i usługa DNS w usłudze Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

W tym artykule pokazano, jak uwidocznić zasób PaaS za pośrednictwem prywatnego punktu końcowego do określonego obciążenia w jednym regionie. W tym scenariuszu topologia sieci jest piastą i szprychą, a piasta jest koncentratorem usługi Azure Virtual WAN.

Ważne

Ten artykuł jest częścią serii usług Azure Private Link i Azure DNS w usłudze Virtual WAN i opiera się na topologii sieci zdefiniowanej w przewodniku scenariusza. Najpierw przeczytaj stronę przeglądu, aby zrozumieć podstawową architekturę sieci i kluczowe wyzwania.

Scenariusz

Rysunek 1. Scenariusz usługi Virtual WAN z usługą Private Link i usługą Azure DNS — wyzwanie

Pobierz plik programu Visio tej architektury. W tej sekcji zdefiniowano scenariusz i zdefiniowano ponownie wyzwanie dla tego scenariusza (wyzwanie jest takie samo jak przykład nieworkingowy na stronie przeglądu). Początkowa architektura scenariusza opiera się na początkowej topologii sieci zdefiniowanej w przewodniku przeglądu. Poniżej przedstawiono dodatki i zmiany:

Istnieje tylko jeden region z jednym koncentratorem wirtualnym.
W regionie, w którym jest wyłączony dostęp do sieci publicznej, istnieje konto usługi Azure Storage. Założeniem w tym scenariuszu jest to, że tylko jedno obciążenie uzyskuje dostęp do konta magazynu.
Początkowo istnieje jedna sieć wirtualna połączona z koncentratorem wirtualnym.
Sieć wirtualna ma podsieć obciążenia zawierającą klienta maszyny wirtualnej.
Sieć wirtualna zawiera podsieć prywatnego punktu końcowego zawierającą prywatny punkt końcowy dla konta magazynu.

Pomyślny wynik

Klient maszyny wirtualnej platformy Azure może nawiązać połączenie z kontem usługi Azure Storage za pośrednictwem prywatnego punktu końcowego konta magazynu, który znajduje się w tej samej sieci wirtualnej, a cały inny dostęp do konta magazynu jest zablokowany.

Przeszkody

Potrzebny jest rekord DNS w przepływie DNS, który jest w stanie rozpoznać w pełni kwalifikowaną nazwę domeny (FQDN) konta magazynu z powrotem do prywatnego adresu IP prywatnego punktu końcowego. Jak określono w omówieniu, wyzwanie ze scenariuszem jest dwa razy:

Nie można połączyć prywatnej strefy DNS, która obsługuje konta magazynu niezbędne rekordy DNS do koncentratora wirtualnego.
Możesz połączyć prywatną strefę DNS z siecią obciążenia, aby można było pomyśleć, że będzie działać. Niestety architektura punktu odniesienia przewiduje, że każda połączona sieć wirtualna ma serwery DNS skonfigurowane tak, aby wskazywały korzystanie z serwera proxy DNS usługi Azure Firewall.

Ponieważ nie można połączyć prywatnej strefy DNS z koncentratorem wirtualnym, a sieć wirtualna jest skonfigurowana do korzystania z serwera proxy DNS usługi Azure Firewall, serwery Usługi Azure DNS nie mają żadnego mechanizmu rozpoznawania (FQDN) konta magazynu z prywatnym adresem IP prywatnego punktu końcowego. Wynikiem jest to, że klient otrzymuje błędną odpowiedź DNS.

Przepływy DNS i HTTP

Przejrzyjmy system DNS i wynikowe przepływy żądań HTTP dla tego obciążenia. Przegląd pomaga nam wizualizować przeszkodę opisaną wcześniej.

Rysunek 2. Scenariusz z jedną regionem dla usługi Virtual WAN z usługą Private Link i usługą Azure DNS — wyzwanie

Pobierz plik programu Visio z tą architekturą.

Przepływ DNS

Zapytanie stgworkload00.blob.core.windows.net DNS od klienta jest wysyłane do skonfigurowanego serwera DNS, który jest usługą Azure Firewall w równorzędnym centrum regionalnym.
Usługa Azure Firewall proxy wysyła żądanie do usługi Azure DNS. Ponieważ nie można połączyć prywatnej strefy DNS z koncentratorem wirtualnym, usługa Azure DNS nie wie, jak rozpoznać nazwę FQDN z prywatnym adresem IP prywatnego punktu końcowego. Wie, jak rozpoznać nazwę FQDN na publiczny adres IP konta magazynu, dlatego zwraca publiczny adres IP konta magazynu.

Przepływ HTTP

Dzięki wynikowi DNS publiczny adres IP konta magazynu klient wysyła żądanie HTTP do stgworkload00.blob.core.windows.net.
Żądanie jest wysyłane do publicznego adresu IP konta magazynu. To żądanie kończy się niepowodzeniem z wielu powodów:
- Sieciowa grupa zabezpieczeń w podsieci obciążenia może nie zezwalać na ten ruch związany z Internetem.
- Usługa Azure Firewall, która filtruje ruch wychodzący powiązany z Internetem, prawdopodobnie nie ma reguły aplikacji do obsługi tego przepływu.
- Nawet jeśli zarówno sieciowa grupa zabezpieczeń, jak i usługa Azure Firewall miały przydziały dla tego przepływu żądań, konto magazynu jest skonfigurowane do blokowania dostępu do całej sieci publicznej. Próba ostatecznie narusza nasz cel zezwalania tylko na dostęp do konta magazynu za pośrednictwem prywatnego punktu końcowego.

Rozwiązanie — ustanawianie rozszerzenia koncentratora wirtualnego dla systemu DNS

Rozwiązaniem tego problemu jest wdrożenie rozszerzenia koncentratora wirtualnego dla systemu DNS przez zespół ds. sieci przedsiębiorstwa. Jedną odpowiedzialnością za rozszerzenie koncentratora wirtualnego DNS jest umożliwienie zespołom obciążeń, które muszą używać prywatnych stref DNS w swojej architekturze w ramach tej początkowej topologii koncentratora usługi Virtual WAN.

Rozszerzenie DNS jest implementowane jako szprycha sieci wirtualnej, która jest równorzędna z regionalnym koncentratorem wirtualnym. Istnieje możliwość połączenia prywatnych stref DNS z tą siecią wirtualną. Sieć wirtualna zawiera również prywatny program rozpoznawania nazw DNS platformy Azure, który umożliwia usługom spoza tej sieci wirtualnej, takim jak Usługa Azure Firewall, wykonywanie zapytań i odbieranie wartości ze wszystkich połączonych prywatnych stref DNS. Poniżej przedstawiono składniki typowego rozszerzenia koncentratora wirtualnego dla systemu DNS wraz z pewnymi wymaganymi zmianami konfiguracji:

Nowa sieć wirtualna szprychy, która jest równorzędna z koncentratorem wirtualnym regionu. Ta szprycha jest skonfigurowana jak każda inna szprycha, co oznacza, że domyślny serwer DNS i reguły routingu wymuszają użycie usługi Azure Firewall w centrum regionalnym.
Zasób prywatnego rozpoznawania nazw DNS jest wdrażany z przychodzącym punktem końcowym w sieci wirtualnej będącej szprychą.
Zostanie utworzony zasób prywatnej strefy DNS o nazwie privatelink.blob.core.windows.net .
- Ta strefa zawiera rekord mapujący A nazwę FQDN konta magazynu na prywatny adres IP prywatnego punktu końcowego dla konta magazynu.
- Prywatna strefa DNS jest połączona z siecią wirtualną będącej szprychą.
- Jeśli kontrola dostępu oparta na rolach (RBAC) umożliwia automatyczną rejestrację lub wpisy zarządzane przez usługę, aby zachować te rekordy DNS. Jeśli nie, możesz je obsługiwać ręcznie.
W centrum regionalnym serwer DNS usługi Azure Firewall jest zmieniany tak, aby wskazywał na przychodzący punkt końcowy prywatnego rozpoznawania nazw DNS.

Na poniższym diagramie przedstawiono architekturę wraz z przepływami DNS i HTTP.

Rysunek 3. Działające rozwiązanie dla scenariusza z pojedynczym regionem dla usługi Virtual WAN z usługą Private Link i usługą DNS

Pobierz plik programu Visio z tą architekturą.

Przepływ DNS dla ustanowienia rozszerzenia koncentratora wirtualnego dla systemu DNS

Zapytanie stgworkload00.blob.core.windows.net DNS od klienta jest wysyłane do skonfigurowanego serwera DNS, który jest usługą Azure Firewall w równorzędnym centrum regionalnym — 10.100.0.132 w tym przypadku.

Rysunek 4. Konfiguracja serwerów DNS dla sieci wirtualnej obciążenia
Usługa Azure Firewall wysyła żądanie do regionalnego prywatnego rozpoznawania nazw AZURE DNS w rozszerzeniu centrum — 10.200.1.4 w tym przypadku, czyli prywatny adres IP przychodzącego punktu końcowego prywatnego rozpoznawania nazw DNS.

Zrzut ekranu przedstawiający zasady usługi Azure Firewall, w których jest włączony serwer proxy DNS, a serwery DNS są ustawione na Wartość niestandardowa. Wpis wskazuje prywatny adres IP punktu końcowego wejściowego prywatnego rozpoznawania nazw DNS.

Rysunek 5. Konfiguracja dns w zasadach usługi Azure Firewall
Prywatny program rozpoznawania nazw DNS proxy żądań do usługi Azure DNS. Ponieważ prywatna strefa DNS jest połączona z siecią wirtualną zawierającą przychodzący punkt końcowy, usługa Azure DNS może używać rekordów w tych połączonych prywatnych strefach DNS.

Rysunek 6. Łącza sieci wirtualnej strefy Prywatna strefa DNS
Usługa Azure DNS sprawdza połączoną prywatną strefę DNS i rozpoznaje nazwę FQDN z adresem stgworkload00.blob.core.windows.net 10.1.2.4, czyli adresem IP prywatnego punktu końcowego dla konta magazynu. Ta odpowiedź jest dostarczana do usługi Azure Firewall DNS, która następnie zwraca prywatny adres IP konta magazynu do klienta.

Rysunek 7. Strefa Prywatna strefa DNS z rekordem A dla prywatnego punktu końcowego konta magazynu

Przepływ HTTP

Dzięki wynikowi DNS prywatny adres IP konta magazynu klient wysyła żądanie HTTP do stgworkload00.blob.core.windows.net.
Żądanie jest wysyłane do prywatnego adresu IP (10.1.2.4) konta magazynu. To żądanie kieruje pomyślnie, zakładając, że nie ma żadnych ograniczeń powodujących konflikt w lokalnych sieciowych grupach zabezpieczeń w podsieci klienta lub podsieci prywatnego punktu końcowego. Należy pamiętać, że mimo że usługa Azure Firewall zabezpiecza ruch prywatny, żądanie nie jest kierowane przez usługę Azure Firewall, ponieważ prywatny punkt końcowy znajduje się w tej samej sieci wirtualnej co klient. Oznacza to, że w tym scenariuszu nie trzeba wprowadzać żadnych dodatków usługi Azure Firewall.
Połączenie prywatne z kontem magazynu jest ustanawiane za pośrednictwem usługi Private Link. Konto magazynu zezwala tylko na dostęp do sieci prywatnej i akceptuje żądanie HTTP.

Rozszerzenie koncentratora wirtualnego dla zagadnień dotyczących systemu DNS

Podczas implementowania rozszerzenia dla przedsiębiorstwa należy wziąć pod uwagę następujące wskazówki.

Wdrażanie rozszerzenia DNS nie jest zadaniem zespołu ds. obciążeń. To zadanie jest funkcją sieciową przedsiębiorstwa i powinno być decyzją implementacji podjętą z tymi osobami.
Rozszerzenie DNS i prywatne strefy DNS muszą istnieć przed dodaniem dowolnej usługi PaaS, dla której chcesz skonfigurować rekordy DNS prywatnego punktu końcowego.
Rozszerzenie koncentratora wirtualnego to zasób regionalny, unikaj ruchu między regionami i ustanawiaj rozszerzenie koncentratora dla każdego centrum regionalnego, w którym oczekiwane jest rozpoznawanie nazw DNS prywatnego punktu końcowego.

Sieć wirtualna szprychy

Zgodnie z jedną zasadą odpowiedzialności sieć wirtualna dla rozszerzenia DNS powinna zawierać tylko zasoby wymagane do rozpoznawania nazw DNS i nie powinny być współużytkowane z innymi zasobami.
Sieć wirtualna rozszerzenia DNS powinna być zgodna z tymi samymi wytycznymi konfiguracji w obszarze Dodawanie sieci szprych.

Azure DNS Private Resolver

Każdy region powinien mieć jedno rozszerzenie DNS koncentratora wirtualnego z jednym prywatnym rozpoznawaniem nazw DNS.
Prywatny program rozpoznawania nazw DNS wymaga tylko przychodzącego punktu końcowego i nie ma wychodzących punktów końcowych w tym scenariuszu. Prywatny adres IP dla przychodzącego punktu końcowego jest ustawiony dla niestandardowej usługi DNS w zasadach usługi Azure Firewall (zobacz rysunek 5).
Aby uzyskać większą odporność i zwiększoną obsługę obciążenia, można wdrożyć wiele wystąpień rozpoznawania prywatnego DNS na region, z serwerem proxy usługi Azure DNS skonfigurowanym z wieloma adresami IP na potrzeby rozpoznawania proxied.

Rysunek 8. Przychodzące punkty końcowe dla prywatnego rozpoznawania nazw DNS
Postępuj zgodnie z ograniczeniami sieci wirtualnej dla prywatnego rozpoznawania nazw DNS.
Sieciowa grupa zabezpieczeń w podsieci dla przychodzącego punktu końcowego rozpoznawania nazw DNS powinna zezwalać tylko na ruch UDP z jego regionalnego centrum do portu 53. Należy zablokować cały inny ruch przychodzący i wychodzący.

Prywatna strefa DNS

Ponieważ prywatny program rozpoznawania nazw DNS platformy Azure rozpoznaje system DNS za pośrednictwem usługi Azure DNS, usługa Azure DNS może odebrać wszystkie prywatne strefy DNS połączone z siecią wirtualną podsieci przychodzącej.

Połącz prywatną strefę DNS z rozszerzeniem koncentratora wirtualnego dla sieci wirtualnej DNS.
Postępuj zgodnie ze wskazówkami dotyczącymi zarządzania prywatnymi strefami DNS dla prywatnych punktów końcowych.
Jeśli oczekujesz, że właściciele zasobów PaaS będą zarządzać własnymi wpisami, skonfiguruj odpowiednio kontrolę dostępu opartą na rolach lub zaimplementuj rozwiązanie, takie jak rozwiązanie z usługi Private Link i integracja dns na dużą skalę.

Zagadnienia dotyczące scenariusza

W przypadku dobrze zarządzanego rozszerzenia DNS koncentratora wirtualnego wróćmy do obciążenia i rozwiążemy kilka dodatkowych kwestii, aby pomóc osiągnąć cele pomyślnego wyniku w tym scenariuszu.

Konto magazynu

Ustaw dostęp do sieci publicznej: wyłączone w obszarze Łączność sieciowa, aby upewnić się, że dostęp do konta magazynu można uzyskać tylko za pośrednictwem prywatnych punktów końcowych.
Dodaj prywatny punkt końcowy do dedykowanej podsieci prywatnego punktu końcowego w sieci wirtualnej obciążenia.
Wyślij Diagnostyka Azure do obszaru roboczego usługi Log Analytics obciążenia. Możesz użyć dzienników dostępu, aby rozwiązać problemy z konfiguracją.

Zabezpieczenia prywatnego punktu końcowego

Wymaganie tego rozwiązania polega na ograniczeniu narażenia tego konta magazynu. Po usunięciu publicznego dostępu do Internetu do zasobu PaaS należy rozwiązać problemy z zabezpieczeniami sieci prywatnej.

Gdy usługa Azure Firewall zabezpiecza ruch prywatny w topologii piasty i szprych wirtualnej sieci WAN, usługa Azure Firewall domyślnie odmawia łączności szprychy z szprychą. To ustawienie domyślne uniemożliwia obciążenia w innych sieciach szprychy uzyskiwanie dostępu do prywatnych punktów końcowych (i innych zasobów) w sieci wirtualnej obciążenia. Ruch w pełni w sieci wirtualnej nie jest kierowany przez usługę Azure Firewall. Aby kontrolować dostęp w sieci wirtualnej i dodać bardziej szczegółową ochronę, należy wziąć pod uwagę następujące zalecenia sieciowej grupy zabezpieczeń.

Utwórz grupę zabezpieczeń aplikacji (ASG) w celu grupowania zasobów, które mają podobne potrzeby dostępu przychodzącego lub wychodzącego. W tym scenariuszu należy użyć grupy ASG dla maszyn wirtualnych klienta, które muszą uzyskać dostęp do magazynu i jedną dla kont magazynu, do których uzyskuje się dostęp. Zobacz Konfigurowanie grupy zabezpieczeń aplikacji (ASG) przy użyciu prywatnego punktu końcowego.
Upewnij się, że podsieć zawierająca maszynę wirtualną obciążenia ma sieciową grupę zabezpieczeń.
Upewnij się, że podsieć zawierająca prywatne punkty końcowe ma sieciową grupę zabezpieczeń.

Reguły sieciowej grupy zabezpieczeń dla podsieci zawierającej maszynę wirtualną obciążenia

Oprócz innych reguł sieci, których wymaga obciążenie, skonfiguruj następujące reguły.

Reguły ruchu wychodzącego:
- Zezwalaj usłudze ASG zasobów obliczeniowych na dostęp do usługi ASG konta magazynu.
- Zezwól usłudze ASG obliczeniowej na prywatny adres IP usługi Azure Firewall dla protokołu UDP na porcie 53.

*Rysunek 9. Reguły sieciowej grupy zabezpieczeń dla podsieci obciążenia

Reguły sieciowej grupy zabezpieczeń dla podsieci zawierającej prywatne punkty końcowe

Najlepszym rozwiązaniem jest uwidacznienie prywatnych punktów końcowych w małej, dedykowanej podsieci w ramach zużywanej sieci wirtualnej. Jednym z powodów jest możliwość zastosowania tras zdefiniowanych przez użytkownika i zasad sieciowych grup zabezpieczeń dla prywatnych punktów końcowych w celu zapewnienia dodatkowej kontroli ruchu i zabezpieczeń.

Ten scenariusz umożliwia zastosowanie wysoce restrykcyjnej sieciowej grupy zabezpieczeń.

Reguły ruchu przychodzącego:
- Zezwalaj usłudze ASG zasobów obliczeniowych na dostęp do usługi ASG konta magazynu
- Odmów całego innego ruchu
Reguły ruchu wychodzącego:
- Odmów całego ruchu

*Rysunek 10. Reguły sieciowej grupy zabezpieczeń dla podsieci prywatnego punktu końcowego

Zabezpieczenia prywatnego punktu końcowego w działaniu

Na poniższej ilustracji pokazano, jak poniżej przedstawiono zagadnienia, które zostały przedstawione, mogą zapewnić zabezpieczenia w głębi systemu obrony. Diagram przedstawia drugą sieć wirtualną szprych z drugą maszyną wirtualną. To obciążenie nie może uzyskać dostępu do prywatnego punktu końcowego.

Rysunek 11. Działające rozwiązanie dla scenariusza z pojedynczym regionem dla usługi Virtual WAN z usługą Private Link i usługą DNS

Pobierz plik programu Visio z tą architekturą.

Przepływ DNS

Przepływ DNS jest dokładnie taki sam jak w przepływie rozwiązania.

Ważne jest, aby podkreślić, że nazwa FQDN jest rozpoznawana jako prywatny adres IP, a nie publiczny adres IP. Ta rozdzielczość oznacza, że wszystkie szprychy zawsze otrzymują prywatny adres IP tej usługi. W innym scenariuszu opisano, jak można użyć tego podejścia do udostępniania usługi PaaS w wielu obciążeniach zużywających wiele. W przypadku tego scenariusza z pojedynczym obciążeniem nie jest to problem.

Przepływ HTTP

Dzięki wynikowi DNS prywatny adres IP konta magazynu klient wysyła żądanie HTTP do stgworkload00.blob.core.windows.net.
Żądanie jest wysyłane na prywatny adres IP konta magazynu. To żądanie odpowiednio kończy się niepowodzeniem z wielu powodów:
- Usługa Azure Firewall jest skonfigurowana do zabezpieczania ruchu prywatnego, więc obsługuje żądanie. Jeśli usługa Azure Firewall nie ma reguły sieciowej lub aplikacji, aby zezwolić na przepływ, usługa Azure Firewall blokuje żądanie.
- Nie musisz używać usługi Azure Firewall w centrum do zabezpieczania ruchu prywatnego. Jeśli na przykład sieć obsługuje ruch prywatny, między regionami, sieciowa grupa zabezpieczeń w podsieci prywatnego punktu końcowego jest nadal skonfigurowana do blokowania całego ruchu innego niż obliczeniowe źródła asg w sieci wirtualnej, która hostuje obciążenie.

Podsumowanie

W tym artykule przedstawiono scenariusz, w którym klient maszyny wirtualnej łączy się z kontem usługi Azure Storage za pośrednictwem prywatnego punktu końcowego konta magazynu. Punkt końcowy znajduje się w tej samej sieci wirtualnej co klient. Cały inny dostęp do konta magazynu jest zablokowany. Ten scenariusz wymaga rekordu DNS w przepływie DNS, który może rozpoznać w pełni kwalifikowaną nazwę domeny (FQDN) konta magazynu z powrotem do prywatnego adresu IP prywatnego punktu końcowego.

Topologia sieci początkowej dla tego scenariusza stanowi dwa wyzwania:

Nie można połączyć prywatnej strefy DNS z wymaganymi rekordami DNS dla konta magazynu do koncentratora wirtualnego.
Łączenie prywatnej strefy DNS z podsiecią obciążenia nie działa. Początkowa topologia sieci wymaga, aby domyślny serwer DNS i reguły routingu wymuszały użycie usługi Azure Firewall w centrum regionalnym.

Proponowane rozwiązanie jest przeznaczone dla zespołu ds. sieci przedsiębiorstwa w celu zaimplementowania rozszerzenia koncentratora wirtualnego dla systemu DNS. To rozszerzenie umożliwia zespołowi sieci przedsiębiorstwa uwidacznienie udostępnionych usług DNS szprych obciążenia, które ich wymagają.

Udostępnij za pośrednictwem

Scenariusz z pojedynczym regionem — usługa Private Link i usługa DNS w usłudze Azure Virtual WAN