Azure P2S DNS zawodzi, gdy resolver jest w połączonej VNet

Klient może dotrzeć do własnej sieci wirtualnej i nadal nie rozwiązywać nazw w sieci połączonej. Peering nie jest tranzytem bramy, dopóki obie strony tego nie powiedzą.

Wyślij ping do VM, a ona odpowie; zapytaj o jej nazwę, a klient mówi, że host jest nieznany. Gdy resolver znajduje się w połączonej sieci wirtualnej, a nie w tej, która zawiera bramę VPN, ta para wyników jest oczekiwana i żadna diagnostyka resolvera tego nie zmieni. Brakuje umowy routingu, którą peering domyślnie wstrzymuje. Dwie topologie wyglądają na papierze prawie identycznie, a różnica między działającą i zepsutą to para przełączników peeringu ustawionych w właściwym kierunku.

Wyobraź sobie laptopa tunelującego do bramy w VNet2, podczas gdy kontroler domeny obsługujący DNS siedzi w VNet1.

Dwie topologie, jedna różnica

Umieść resolver we własnej sieci wirtualnej bramy, a nazwa zostanie rozwiązana w chwili, gdy tunel się podniesie. Żadne ustawienie peeringu nie bierze udziału w tym wyszukiwaniu.

Przenieś ten sam resolver przez peering, a klient nadal otrzymuje odpowiedź od VM, podczas gdy nazwa pozostaje nieznana. Certyfikat, tunel i klient są bez zmian. Jedyne, co się przesunęło, to miejsce, w którym mieszka resolver. Peering dał mu trasę do tego adresu, a nie upoważnienie bramy do przewożenia tam ruchu.

Strona A: zezwól na tranzyt bramy u właściciela bramy

Peering łączy dwie sieci wirtualne, ale połączenie nie jest tranzytywne dla ruchu przychodzącego przez bramę, a żądanie typu point-to-site przychodzi dokładnie tak. Brama w VNet2 nie ma więc podstaw, by przekazać wyszukiwanie do VNet1, dopóki projekt na to nie pozwoli. Zezwoleniem jest przełącznik na peeringu należącym do sieci z bramą.

Ustaw Allow gateway transit na peeringu VNet2 w kierunku VNet1. Właściwość należy do obiektu peeringu, a nie do zasobu bramy, więc czytasz ją i zmieniasz w bloku peeringu. To cała strona A.

Strona B: użyj zdalnych bram u partnera

Druga połowa to odbicie lustrzane: na peeringu VNet1 z powrotem do VNet2 włącz Use remote gateways. Włączenie tej samej flagi na obu końcach, albo tylko na jednym, pozostawia na wpół zbudowaną ścieżkę i pierwotny objaw nietknięty. Tylko sieć z bramą VPN zezwala na tranzyt, a partner to strona, która go używa.

Czytaj obie właściwości w obu sieciach, zamiast ufać blokowi portalu otwartemu ostatnio.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Zobaczenie pary obok siebie to najszybszy sposób wyłapania odwróconego ustawienia. Peering, który zgłasza AllowGatewayTransit false po stronie bramy, wyjaśnia całą awarię bez przechwytywania pakietów.

Co klient musi jeszcze otrzymać

Routing jest konieczny, ale niewystarczający, bo profil point-to-site musi też dać klientowi adres DNS, który odpowiada, gdy tranzyt działa. Resolver platformy nie jest tym adresem: odpowiada na strefy Azure Private DNS powiązane z siecią wirtualną, ale nic dla strefy hostowanej na twoich własnych serwerach katalogowych, a właśnie tego używa to wdrożenie. Wskaż na niego klienta, a nazwy publiczne będą wesoło rozwiązywane, podczas gdy host wewnętrzny pozostanie nieznany.

Zapytaj resolver z podłączonego laptopa, zanim zmienisz cokolwiek innego.

nslookup dc01.corp.example 10.1.0.4

Przekroczenie limitu czasu mówi, że ścieżka nadal nie istnieje. Odpowiedź autorytatywna odpycha problem z powrotem do klienta, zwykle sufiks, który nigdy nie jest dodawany, więc krótkie nazwy trafiają do publicznego resolvera, który wesoło je zawodzi.

Porównaj tę samą umowę po stronie site-to-site

Nic z tego nie należy szczególnie do laptopów. Zastąp klienta oddziałem w site-to-site, a dwustronny wymóg wraca: oddział trafia bezpośrednio do sieci bramy, a usługa dwie sieci dalej nadal jest za peeringiem.

Tranzyt musi być przyznany na obu peeringach, a przełącznik, który go przyznaje, mieszka na peeringu, a nie na typie klienta.

Zanim obwinisz bramę

Windows trzyma listę resolverów dla każdego adaptera, więc potwierdź, co faktycznie otrzymał interfejs tunelu, zanim obwinisz bramę.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Odpowiedź negatywna przeżywa poprawkę routingu w pamięci podręcznej, a nieaktualna lista sufiksów dalej wysyła zapytania tam, gdzie strefa nigdy nie była hostowana. Wyczyść, zapytaj ponownie i zanotuj, który serwer odpowiada.

Dwa mniejsze warunki decydują, czy ścieżka się utrzyma: przestrzenie adresowe nie mogą na siebie nachodzić, a grupa zabezpieczeń sieci w podsieci resolvera musi wpuścić pulę klientów, która jest tylko kolejnym zakresem źródłowym. Udowodnij to sprawdzeniem efektywnych tras po stronie VM plus jednym bezpośrednim zapytaniem od klienta, aby problem strefy, problem sufiksu lub filtr nigdy nie zostały pomylone z brakującym tranzytem.

Powiązane artykuły