Azure P2S DNS ne uspijeva kada je resolver u peerovanoj VNet

Klijent može dosegnuti svoju virtualnu mrežu, a ipak ne može razriješiti imena u peerovanoj mreži. Peering nije tranzit gatewaya dok obje strane to ne dopuste.

Pošaljite ping na VM i ona odgovara; pitajte za njeno ime i klijent kaže da je host nepoznat. Kada resolver stoji u peerovanoj virtualnoj mreži, a ne u onoj koja drži VPN gateway, taj par rezultata je očekivan i nikakvo otklanjanje problema s resolverom to ne mijenja. Nedostaje ugovor o rutiranju koji peering po defaultu uskraćuje. Dvije topologije izgledaju gotovo identično na papiru, a razlika između radnog i pokvarenog je par peering prekidača postavljenih u pravom smjeru.

Zamislite laptop koji tunelira u gateway u VNet2, dok kontroler domene koji služi DNS sjedi u VNet1.

Dvije topologije, jedna razlika

Stavite resolver unutar gatewayove vlastite virtualne mreže i ime se razriješi čim tunel uspostavi vezu. Nijedna peering postavka ne sudjeluje u tom pretraživanju.

Premjestite isti resolver preko peeringa i klijent i dalje dobija odgovor od VM-a dok ime ostaje nepoznato. Certifikat, tunel i klijent su nepromijenjeni. Jedino što se pomjerilo jeste gdje resolver živi. Peering mu je dao rutu do te adrese, ne ovlaštenje gatewayu da tamo nosi promet.

Strana A: dopustite tranzit gatewaya kod vlasnika gatewaya

Peering spaja dvije virtualne mreže, ali spoj nije tranzitivan za promet koji dolazi kroz gateway, a zahtjev point-to-site dolazi upravo tako. Gateway u VNet2 zato nema osnova predati pretragu u VNet1 dok mu dizajn to ne dopusti. Dopuštenje je prekidač na peeringu koji posjeduje mreža s gatewayem.

Postavite Allow gateway transit na peeringu VNet2 prema VNet1. Svojstvo pripada objektu peeringa, ne resursu gatewaya, pa ga čitate i mijenjate na oštrici peeringa. To je cijela strana A.

Strana B: koristite udaljene gatewaye na peeru

Druga polovina je zrcalna slika: na peeringu VNet1 natrag prema VNet2 uključite Use remote gateways. Uključivanje iste zastavice na oba kraja, ili samo na jednom, ostavlja poluizgrađenu putanju i izvorni simptom netaknutim. Samo mreža s VPN gatewayem dopušta tranzit, a peer je strana koja ga koristi.

Čitajte oba svojstva na obje mreže umjesto da vjerujete oštrici portala koju ste zadnju otvorili.

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

Vidjeti par jedan uz drugi najbrži je način da uhvatite obrnutu postavku. Peering koji prijavljuje AllowGatewayTransit false na strani gatewaya objašnjava cijeli kvar bez hvatanja paketa.

Šta klijent još mora dobiti

Rutiranje je nužno, ali ne i dovoljno, jer profil point-to-site mora klijentu predati i DNS adresu koja odgovara kada tranzit proradi. Platformski resolver nije ta adresa: odgovara za Azure Private DNS zone povezane s virtualnom mrežom, ali ništa za zonu hostovanu na vašim vlastitim direktorijskim serverima, a to je ono što ovo postavljanje koristi. Usmjerite klijenta na njega i javna imena se veselo razrješavaju dok unutrašnji host ostaje nepoznat.

Pitajte resolver s povezanog laptopa prije nego što promijenite bilo šta drugo.

nslookup dc01.corp.example 10.1.0.4

Istek vremena kaže da putanja još nedostaje. Autoritativan odgovor vraća problem klijentu, obično sufiks koji se nikad ne dodaje, pa kratka imena putuju do javnog resolvera koji ih veselo odbija.

Uporedite isti ugovor na strani site-to-site

Ništa od ovoga posebno ne pripada laptopima. Zamijenite klijenta ogrankom na site-to-site i dvostrani zahtjev se vraća: ogranak dolazi direktno u gateway mrežu, a servis dvije mreže dalje i dalje je iza peeringa.

Tranzit se mora dopustiti na oba peeringa, a prekidač koji ga daje živi na peeringu, ne na tipu klijenta.

Prije nego okrivite gateway

Windows drži listu resolvera po adapteru, pa potvrdite šta je tunelski interfejs stvarno dobio prije nego okrivite gateway.

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

Negativan odgovor nadživi popravku rutiranja u kešu, a zastarjela lista sufiksa nastavlja slati upite negdje gdje zona nikad nije bila hostovana. Očistite keš, pitajte ponovo i zabilježite koji server odgovara.

Dva manja uslova odlučuju da li putanja drži: adresni prostori se ne smiju preklapati, a mrežna sigurnosna grupa na resolverovoj podmreži mora propustiti klijentski pool, koji je samo još jedan izvorni opseg. Dokažite to provjerom efektivnih ruta s VM strane plus jednim direktnim upitom s klijenta, da se problem zone, problem sufiksa ili filter nikad ne pobrkaju s nedostajućim tranzitom.

Povezani članci