Udostępnij za pośrednictwem

Prywatne punkty końcowe i zestawy reguł rozpoznawania nazw usługi Azure DNS

  • Artykuł

Z tego artykułu dowiesz się więcej o składnikach prywatnego rozpoznawania nazw usługi Azure DNS. Omówiono przychodzące punkty końcowe, wychodzące punkty końcowe i zestawy reguł przesyłania dalej DNS. Opisano właściwości i ustawienia tych składników, a przykłady służą do ich używania.

Architektura usługi Azure DNS Private Resolver została podsumowana na poniższej ilustracji. W tej przykładowej sieci program rozpoznawania nazw DNS jest wdrażany w sieci wirtualnej piasty, która jest równorzędna z siecią wirtualną będącej szprychą.

Diagram przedstawiający architekturę prywatnego rozpoznawania nazw

Rysunek 1. Przykładowa sieć piasty i szprych z rozpoznawaniem nazw DNS

  • Linki zestawu reguł są aprowizowane w zestawie reguł przesyłania dalej DNS zarówno do sieci wirtualnych piasty, jak i szprych, umożliwiając zasoby w obu sieciach wirtualnych rozpoznawanie niestandardowych przestrzeni nazw DNS przy użyciu reguł przekazywania DNS.
  • Prywatna strefa DNS jest również wdrażana i połączona z siecią wirtualną koncentratora, umożliwiając zasobom w sieci wirtualnej koncentratora rozpoznawanie rekordów w strefie.
  • Sieć wirtualna szprychy rozpoznaje rekordy w strefie prywatnej przy użyciu reguły przekazywania DNS, która przekazuje zapytania strefy prywatnej do przychodzącego adresu VIP punktu końcowego w sieci wirtualnej piasty.
  • Na rysunku pokazano również sieć lokalną połączoną z usługą ExpressRoute z serwerami DNS skonfigurowanymi do przekazywania zapytań dla strefy prywatnej platformy Azure do przychodzącego adresu VIP punktu końcowego. Aby uzyskać więcej informacji na temat włączania hybrydowego rozpoznawania nazw DNS przy użyciu prywatnego rozpoznawania nazw DNS platformy Azure, zobacz Rozwiązywanie problemów z platformą Azure i domenami lokalnymi.

Uwaga

Połączenie komunikacji równorzędnej pokazane na diagramie nie jest wymagane do rozpoznawania nazw. Sieci wirtualne połączone z zestawu reguł przesyłania dalej DNS używają zestawu reguł podczas rozpoznawania nazw, niezależnie od tego, czy połączone sieci wirtualne równorzędne z siecią wirtualną zestawu reguł.

Przychodzące punkty końcowe

Jak sugeruje nazwa, przychodzące punkty końcowe są przychodzące do platformy Azure. Przychodzące punkty końcowe zapewniają adres IP do przekazywania zapytań DNS z lokalizacji lokalnych i innych poza siecią wirtualną. Zapytania DNS wysyłane do przychodzącego punktu końcowego są rozwiązywane przy użyciu usługi Azure DNS. Prywatna strefa DNS strefy połączone z siecią wirtualną, w której aprowizowany jest przychodzący punkt końcowy, są rozpoznawane przez przychodzący punkt końcowy.

Adres IP skojarzony z przychodzącym punktem końcowym jest zawsze częścią prywatnej przestrzeni adresowej sieci wirtualnej, w której wdrożono prywatny program rozpoznawania. Żadne inne zasoby nie mogą istnieć w tej samej podsieci z przychodzącym punktem końcowym.

Statyczne i dynamiczne adresy IP punktów końcowych

Adres IP przypisany do przychodzącego punktu końcowego może być statyczny lub dynamiczny. Jeśli wybierzesz statyczny, nie możesz wybrać zastrzeżonego adresu IP w podsieci. Jeśli wybierzesz dynamiczny adres IP, zostanie przypisany piąty dostępny adres IP w podsieci. Na przykład 10.10.0.4 jest piątym adresem IP w podsieci 10.10.0.0/28 (.0, .1, .2, .3, .4). Jeśli przychodzący punkt końcowy zostanie ponownie zainicjowany, ten adres IP może ulec zmianie, ale zwykle 5. adres IP w podsieci zostanie ponownie użyty. Dynamiczny adres IP nie zmienia się, chyba że przychodzący punkt końcowy zostanie ponownie zaaprowizowany. W poniższym przykładzie określono statyczny adres IP:


Zrzut ekranu przedstawiający sposób wybierania statycznego adresu IP.

W poniższym przykładzie pokazano aprowizowanie przychodzącego punktu końcowego z wirtualnym adresem IP (VIP) 10.10.0.4 wewnątrz podsieci snet-E-inbound w sieci wirtualnej z przestrzenią adresową 10.10.0.0/16.

Zrzut ekranu przedstawiający przychodzące punkty końcowe.

Wychodzące punkty końcowe

Wychodzące punkty końcowe wychodzące z platformy Azure i mogą być połączone z zestawami reguł przesyłania dalej DNS.

Wychodzące punkty końcowe są również częścią prywatnej przestrzeni adresowej sieci wirtualnej, w której wdrożono prywatny program rozpoznawania nazw. Wychodzący punkt końcowy jest skojarzony z podsiecią, ale nie jest aprowizowany przy użyciu adresu IP, takiego jak przychodzący punkt końcowy. Żadne inne zasoby nie mogą istnieć w tej samej podsieci z punktem końcowym ruchu wychodzącego. Poniższy zrzut ekranu przedstawia wychodzący punkt końcowy wewnątrz podsieci snet-E-outbound.

Wyświetlanie wychodzących punktów końcowych

Zestawy reguł przesyłania dalej DNS

Zestawy reguł przesyłania dalej DNS umożliwiają określenie co najmniej jednego niestandardowego serwera DNS w celu odpowiadania na zapytania dotyczące określonych przestrzeni nazw DNS. Poszczególne reguły w zestawie reguł określają sposób rozpoznawania tych nazw DNS. Zestawy reguł mogą być również połączone z co najmniej jedną siecią wirtualną, umożliwiając zasobom w sieciach wirtualnych używanie skonfigurowanych reguł przesyłania dalej.

Zestawy reguł mają następujące skojarzenia:

  • Pojedynczy zestaw reguł może być skojarzony z maksymalnie 2 punktami końcowymi ruchu wychodzącego należącymi do tego samego wystąpienia prywatnego rozpoznawania nazw DNS. Nie można go skojarzyć z 2 punktami końcowymi ruchu wychodzącego w dwóch różnych wystąpieniach prywatnego rozpoznawania nazw DNS.
  • Zestaw reguł może mieć do 1000 reguł przekazywania DNS.
  • Zestaw reguł może być połączony z maksymalnie 500 sieciami wirtualnymi w tym samym regionie.

Nie można połączyć zestawu reguł z siecią wirtualną w innym regionie. Aby uzyskać więcej informacji na temat zestawu reguł i innych limitów prywatnego rozpoznawania nazw, zobacz Jakie są limity użycia dla usługi Azure DNS?.

Po połączeniu zestawu reguł z siecią wirtualną zasoby w tej sieci wirtualnej używają reguł przesyłania dalej DNS włączone w zestawie reguł. Połączone sieci wirtualne nie są wymagane do komunikacji równorzędnej z siecią wirtualną, w której istnieje punkt końcowy ruchu wychodzącego, ale te sieci można skonfigurować jako komunikację równorzędną. Ta konfiguracja jest powszechna w projekcie piasty i szprych. W tym scenariuszu piasty i szprychy sieć wirtualna szprychy nie musi być połączona z prywatną strefą DNS w celu rozpoznawania rekordów zasobów w strefie. W takim przypadku reguła zestawu reguł przesyłania dalej dla strefy prywatnej wysyła zapytania do przychodzącego punktu końcowego sieci wirtualnej koncentratora. Na przykład: azure.contoso.com do 10.10.0.4.

Poniższy zrzut ekranu przedstawia zestaw reguł przesyłania dalej DNS połączony z siecią wirtualną szprych: myeastspoke.

Wyświetlanie łączy zestawu reguł

Linki sieci wirtualnej dla zestawów reguł przesyłania dalej DNS umożliwiają zasoby w innych sieciach wirtualnych do używania reguł przekazywania podczas rozpoznawania nazw DNS. Sieć wirtualna z prywatnym modułem rozpoznawania nazw musi być również połączona z dowolnych prywatnych stref DNS, dla których istnieją reguły zestawu reguł.

Na przykład zasoby w sieci wirtualnej myeastspoke mogą rozpoznawać rekordy w prywatnej strefie azure.contoso.com DNS, jeśli:

  • Zestaw reguł aprowizowany w programie myeastvnet jest połączony z myeastspoke
  • Reguła zestawu reguł jest skonfigurowana i włączona w połączonym zestawie reguł w celu rozwiązania problemu azure.contoso.com przy użyciu przychodzącego punktu końcowego w programie myeastvnet

Uwaga

Możesz również połączyć zestaw reguł z siecią wirtualną w innej subskrypcji platformy Azure. Jednak określona grupa zasobów musi znajdować się w tym samym regionie co prywatny program rozpoznawania nazw.

Reguły

Reguły przesyłania dalej DNS (reguły zestawu reguł) mają następujące właściwości:

Właściwości opis
Nazwa reguły Nazwa reguły. Nazwa musi zaczynać się literą i może zawierać tylko litery, cyfry, podkreślenia i kreski.
Nazwa domeny Przestrzeń nazw DNS z kropką, w której ma zastosowanie reguła. Przestrzeń nazw musi mieć etykiety zerowe (dla symboli wieloznacznych) lub od 1 do 34 etykiet. Na przykład contoso.com. ma dwie etykiety.1
Docelowy adres IP:Port Miejsce docelowe przekazywania. Co najmniej jeden adres IP i porty serwerów DNS używanych do rozpoznawania zapytań DNS w określonej przestrzeni nazw.
Stan reguły Stan reguły: Włączone lub wyłączone. Jeśli reguła jest wyłączona, jest ona ignorowana.

Obsługiwane są nazwy domen z jednąetykietą.

Jeśli dopasuje się wiele reguł, zostanie użyte najdłuższe dopasowanie prefiksu.

Jeśli na przykład masz następujące reguły:

Nazwa reguły Nazwa domeny Docelowy adres IP:Port Stan reguły
Contoso contoso.com. 10.100.0.2:53 Włączona
AzurePrivate azure.contoso.com. 10.10.0.4:53 Włączona
Symbole wieloznaczne . 10.100.0.2:53 Włączona

Zapytanie dla secure.store.azure.contoso.com reguły AzurePrivate azure.contoso.com dla , a także reguły Contoso dla contoso.com, ale reguła AzurePrivate ma pierwszeństwo, ponieważ prefiks azure.contoso jest dłuższy niż contoso.

Ważne

Jeśli reguła znajduje się w zestawie reguł, który ma jako miejsce docelowe prywatnego punktu końcowego rozpoznawania nazw przychodzących, nie należy łączyć zestawu reguł z siecią wirtualną, w której aprowizowany jest przychodzący punkt końcowy. Ta konfiguracja może powodować pętle rozpoznawania nazw DNS. Na przykład: W poprzednim scenariuszu nie należy dodawać myeastvnet linku zestawu reguł, ponieważ przychodzący punkt końcowy w 10.10.0.4 obiekcie jest aprowizowany w myeastvnet programie, a reguła jest obecna, która rozwiązuje problem azure.contoso.com przy użyciu przychodzącego punktu końcowego.

Reguły przedstawione w tym artykule to przykłady reguł, których można użyć w określonych scenariuszach. Użyte przykłady nie są wymagane. Należy zachować ostrożność, aby przetestować reguły przesyłania dalej.

Jeśli w zestawie reguł dołączysz regułę z symbolami wieloznacznymi, upewnij się, że docelowa usługa DNS może rozpoznać publiczne nazwy DNS. Niektóre usługi platformy Azure mają zależności od rozpoznawania nazw publicznych.

Przetwarzanie reguł

  • Jeśli dla reguły wprowadzono wiele serwerów DNS jako miejsce docelowe, zostanie użyty pierwszy wprowadzony adres IP, chyba że nie odpowie. Algorytm wycofywania wykładniczego służy do określania, czy docelowy adres IP odpowiada.
  • Niektóre domeny są ignorowane podczas używania reguły wieloznacznych na potrzeby rozpoznawania nazw DNS, ponieważ są one zarezerwowane dla usług platformy Azure. Zobacz Konfiguracja strefy DNS usług platformy Azure, aby uzyskać listę domen zarezerwowanych. Nazwy DNS z dwiema etykietami wymienione w tym artykule (na przykład: windows.net, azure.com, azure.net, windowsazure.us) są zarezerwowane dla usług platformy Azure.

Ważne

  • Nie można wprowadzić adresu IP usługi Azure DNS 168.63.129.16 jako docelowego adresu IP reguły. Próba dodania tego adresu IP powoduje wyświetlenie błędu: Wyjątek podczas dodawania żądania reguły.
  • Nie używaj adresu IP punktu końcowego ruchu przychodzącego prywatnej usługi rozpoznawania nazw jako miejsca docelowego przekazywania dalej dla stref, które nie są połączone z siecią wirtualną, w której aprowizowano prywatną usługę rozpoznawania nazw.

Opcje projektowania

Sposób wdrażania zestawów reguł przekazywania i przychodzących punktów końcowych w architekturze piasty i szprych idealnie zależy od projektu sieci. Dwie opcje konfiguracji zostały krótko omówione w poniższych sekcjach. Aby uzyskać bardziej szczegółową dyskusję na temat przykładów konfiguracji, zobacz Architektura prywatnego rozpoznawania nazw.

Łączenie zestawu reguł przesyłania dalej z siecią wirtualną umożliwia przekazywanie dns w tej sieci wirtualnej. Jeśli na przykład zestaw reguł zawiera regułę do przekazywania zapytań do przychodzącego punktu końcowego prywatnego rozpoznawania nazw, tego typu reguła może służyć do włączania rozpoznawania stref prywatnych połączonych z siecią wirtualną przychodzącego punktu końcowego. Tej konfiguracji można użyć, gdy sieć wirtualna piasty jest połączona ze strefą prywatną i chcesz włączyć rozpoznawanie strefy prywatnej w sieciach wirtualnych szprych, które nie są połączone ze strefą prywatną. W tym scenariuszu rozpoznawanie nazw DNS strefy prywatnej jest przeprowadzane przez przychodzący punkt końcowy w sieci wirtualnej koncentratora.

Scenariusz projektowania linków zestawu reguł najlepiej nadaje się do rozproszonej architektury DNS, w której ruch sieciowy jest rozłożony w sieci platformy Azure i może być unikatowy w niektórych lokalizacjach. W tym projekcie można kontrolować rozpoznawanie nazw DNS we wszystkich sieciach wirtualnych połączonych z zestawem reguł, modyfikując pojedynczy zestaw reguł.

Uwaga

Jeśli używasz opcji linku zestawu reguł i istnieje reguła przekazywania z przychodzącym punktem końcowym jako miejscem docelowym, nie należy łączyć zestawu reguł przesyłania dalej z siecią wirtualną koncentratora. Połączenie tego typu zestawu reguł z tą samą siecią wirtualną, w której aprowizowany jest przychodzący punkt końcowy, może spowodować pętlę rozpoznawania nazw DNS.

Przychodzące punkty końcowe jako niestandardowe dns

Przychodzące punkty końcowe mogą przetwarzać przychodzące zapytania DNS i można je skonfigurować jako niestandardowy system DNS dla sieci wirtualnej. Ta konfiguracja może zastąpić wystąpienia, w których używasz własnego serwera DNS jako niestandardowego systemu DNS w sieci wirtualnej.

Niestandardowy scenariusz projektowania DNS najlepiej nadaje się do scentralizowanej architektury DNS, w której rozpoznawanie nazw DNS i przepływ ruchu sieciowego są głównie do sieci wirtualnej koncentratora i jest kontrolowany z centralnej lokalizacji.

Aby rozpoznać prywatną strefę DNS z sieci wirtualnej będącej szprychą przy użyciu tej metody, sieć wirtualna, w której istnieje przychodzący punkt końcowy, musi być połączona ze strefą prywatną. Sieć wirtualna piasty może być (opcjonalnie) połączona z zestawem reguł przesyłania dalej. Jeśli zestaw reguł jest połączony z centrum, cały ruch DNS wysyłany do przychodzącego punktu końcowego jest przetwarzany przez zestaw reguł.

Następne kroki