Azure P2S DNS ne uspijeva kada je resolver u povezanoj VNet

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

Pošaljite ping na VM i ona odgovara; pitajte za njezino ime i klijent kaže da je host nepoznat. Kada resolver stoji u povezanoj virtualnoj mreži, a ne u onoj koja drži VPN pristupnik, taj par rezultata je očekivan i nikakvo otklanjanje problema s resolverom to ne mijenja. Nedostaje ugovor o usmjeravanju koji peering prema zadanim postavkama zadržava. 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 prijenosno računalo koje tunelira u pristupnik u VNet2, dok kontroler domene koji služi DNS sjedi u VNet1.

Dvije topologije, jedna razlika

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

Premjestite isti resolver preko peeringa i klijent i dalje dobiva odgovor od VM-a dok ime ostaje nepoznato. Certifikat, tunel i klijent nisu promijenjeni. Jedino što se pomaknulo jest gdje resolver živi. Peering mu je dao rutu do te adrese, ne ovlast pristupniku da tamo nosi promet.

Strana A: dopustite tranzit pristupnika kod vlasnika pristupnika

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

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

Strana B: koristite udaljene pristupnike na peeru

Druga polovica 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 pristupnikom 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 pristupnika objašnjava cijeli kvar bez hvatanja paketa.

Što klijent još mora dobiti

Usmjeravanje 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 hostanu na vašim vlastitim direktorijskim poslužiteljima, a to je ono što ovo postavljanje koristi. Usmjerite klijenta na njega i javna imena se veselo razrješavaju dok unutarnji host ostaje nepoznat.

Pitajte resolver s povezanog prijenosnog računala prije nego što promijenite bilo što 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.

Usporedite isti ugovor na strani site-to-site

Ništa od ovoga posebno ne pripada prijenosnim računalima. Zamijenite klijenta podružnicom na site-to-site i dvostrani zahtjev se vraća: podružnica dolazi izravno u pristupnikovu mrežu, a usluga 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 pristupnik

Windows drži popis resolvera po adapteru, pa potvrdite što je tunelsko sučelje stvarno dobilo prije nego okrivite pristupnik.

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

Negativan odgovor nadživi popravak usmjeravanja u predmemoriji, a zastarjeli popis sufiksa nastavlja slati upite negdje gdje zona nikad nije bila hostana. Očistite, pitajte ponovo i zabilježite koji poslužitelj odgovara.

Dva manja uvjeta odlučuju hoće li putanja izdržati: 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 raspon. Dokažite to provjerom efektivnih ruta s VM strane plus jednim izravnim upitom s klijenta, da se problem zone, problem sufiksa ili filtar nikad ne pobrkaju s nedostajućim tranzitom.

Povezani članci