Prywatny DNS Azure przez VPN: punkt końcowy resolvera czy forwarder
Oba projekty odpowiadają na strefy prywatne przez tunel. Porównaj zarządzany punkt końcowy przychodzący z VM forwardera, a następnie sprawdź ścieżkę, która musi istnieć w obu przypadkach.
Serwer w sieci lokalnej dociera do VM Azure przez adres prywatny i wciąż nie potrafi rozwiązać jego prywatnej nazwy hosta, co skłania ludzi do szukania zepsutego tunelu. Tunel jest w porządku. Brakuje granicy DNS: nic po stronie lokalnej nie wie, że na określoną prywatną strefę Azure musi odpowiedzieć resolver wewnątrz VNet. Dwa projekty wypełniają tę lukę i różnią się tym, czym ostatecznie zarządzasz, a nie tym, czy zapytania działają.
Tunel przenosi zapytania, nie wiedzę o strefach
Połączenie site-to-site daje pakietom trasę między dwiema sieciami. Nie mówi lokalnemu serwerowi DNS, która przestrzeń nazw należy do Azure ani który adres ma odpowiedzieć, więc zapytanie albo wychodzi do internetu i wraca puste, albo nigdy nie opuszcza lokalnego resolvera.
Poprawka ma dwie łatwe do rozdzielenia połowy. Jedna połowa to resolver wewnątrz VNet, który przyjmuje zapytania przychodzące przez tunel. Druga to warunkowy forwarder po stronie lokalnej, który wysyła dokładnie jedną przestrzeń nazw do tego resolvera. Żadna połowa nie działa sama.
Załóżmy, że strefa to cloud.corp.example w dalszej części opisu, a każdy adres traktujmy jako przykładowy.
Opcja A: zarządzany punkt końcowy przychodzący
Azure DNS Private Resolver udostępnia punkt końcowy przychodzący, który przyjmuje zapytania DNS spoza VNet. Wdrażasz go w dedykowanej delegowanej podsieci, łączysz strefę prywatną z tą VNet i notujesz adres przychodzący przydzielony przez usługę.
Na lokalnym serwerze DNS tworzysz następnie warunkowy forwarder dla dokładnej przestrzeni nazw w stronę tego adresu:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Procedura hybrydowego DNS firmy Microsoft opisuje zarówno powiązanie strefy, jak i krok forwardera. Ścieżka zarządzana nie zostawia żadnego oprogramowania DNS do łatania, a adres punktu końcowego pozostaje stabilny przez cały okres życia zasobu.
Ceną jest to, że masz teraz zasób resolvera, jego delegację podsieci i jego koszt, który jest realny nawet przy znikomym wolumenie zapytań.
Opcja B: VM forwardera wewnątrz VNet
Starszy projekt uruchamia oprogramowanie DNS na zwykłej VM w VNet: Windows DNS, BIND lub dnsmasq, a strefa prywatna jest albo hostowana lokalnie, albo przekazywana do resolvera Azure pod 168.63.129.16. Lokalny warunkowy forwarder wskazuje prywatny adres tej VM.
Ta opcja jest znana zespołom, które już utrzymują serwery DNS, i może nieść dodatkową logikę, na przykład logowanie lub odpowiedzi split-horizon. Dziedziczy też wszystkie obowiązki operacyjne serwera DNS: łatanie, drugą instancję dla dostępności, monitorowanie i ścieżkę odbudowy, gdy VM zostaje wymieniona, a jej adres się zmienia.
Zwykły host VNet nie jest proxy DNS, dopóki usługa nie zostanie zainstalowana i nie otrzyma pozwolenia na odpowiadanie tym klientom, i właśnie ten krok ludzie pomijają przy klonowaniu VM.
Która pasuje do twojej działalności
Porównanie nie dotyczy tego, który projekt jest szybszy. Dotyczy tego, czy w ogóle chcesz utrzymywać oprogramowanie DNS, i czy wolumen zapytań uzasadnia zarządzany zasób rozliczany za punkt końcowy i za zapytanie.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Którykolwiek wiersz zdecyduje, reguła forwardera po stronie lokalnej wygląda tak samo. To ta część, która musi istnieć w obu projektach, i ta, której najczęściej brakuje, gdy ktoś zgłasza, że rozwiązywanie działa z wnętrza Azure, ale nie z biura.
Sprawdź ścieżkę po kolei
Potwierdź, że strefa jest powiązana z VNet, która zawiera resolver, i że lokalny forwarder nazywa przestrzeń nazw, a nie domenę nadrzędną. Forwarder dla corp.example nie dopasuje cloud.corp.example, chyba że sam resolver deleguje, a niezgodność daje czystą odpowiedź negatywną, która wygląda jak brakujący rekord.
Następnie sprawdź, czy zapytanie dociera do punktu końcowego: źródło lokalne potrzebuje trasy do adresu resolvera i drogi powrotnej, a port 53 powinien być dozwolony zarówno dla UDP, jak i TCP tam, gdzie polityka na to pozwala. NSG nie dostarczy brakującego rekordu strefy, a poprawna strefa nie odpowie na zapytanie, które nigdy nie dociera.
Diagnozując, trzymaj żądaną nazwę FQDN obok wybranego resolvera, i odróżnij przekroczenie limitu czasu od odpowiedzi negatywnej. Przekroczenie limitu to problem trasy lub polityki. Odpowiedź negatywna oznacza, że zapytanie dotarło, a przestrzeń nazw nie pasowała. Kolejność pracy: powiąż strefę, dodaj warunkowy forwarder, otwórz port 53 w obu kierunkach, przetestuj jedną nazwę z sieci lokalnej i dopiero potem sprawdź autoryzację samej aplikacji.