Azure P2S DNS ne uspe, ko je resolver v povezanem VNet

Odjemalec lahko doseže svoje lastno virtualno omrežje in vseeno ne razreši imen v povezanem omrežju. Peering ni tranzit prehoda, dokler tega ne rečeta obe strani.

Pošljite ping na VM in ta odgovori; vprašajte za njeno ime in odjemalec reče, da je gostitelj neznan. Ko je resolver v povezanem virtualnem omrežju in ne v tistem, ki vsebuje prehod VPN, je ta par rezultatov pričakovan in nobeno odpravljanje težav z resolverjem tega ne spremeni. Manjka dogovor o usmerjanju, ki ga peering privzeto zadržuje. Dve topologiji sta na papirju skoraj enaki, razlika med delujočo in pokvarjeno pa je par stikal peeringa, postavljenih v pravo smer.

Predstavljajte si prenosni računalnik, ki tunelira v prehod v VNet2, medtem ko kontroler domene, ki služi DNS, sedi v VNet1.

Dve topologiji, ena razlika

Postavite resolver v lastno virtualno omrežje prehoda in ime se razreši v trenutku, ko se tunel dvigne. Nobena nastavitev peeringa ne sodeluje pri tem iskanju.

Premaknite isti resolver čez peering in odjemalec še vedno dobi odgovor od VM, ime pa ostane neznano. Potrdilo, tunel in odjemalec so nespremenjeni. Edino, kar se je premaknilo, je, kje živi resolver. Peering mu je dal pot do tega naslova, ne pooblastila prehodu, da bi tja prenašal promet.

Stran A: dovolite tranzit prehoda pri lastniku prehoda

Peering poveže dve virtualni omrežji, vendar povezava ni tranzitivna za promet, ki prihaja skozi prehod, zahteva od točke do lokacije pa prihaja točno tako. Prehod v VNet2 zato nima podlage, da bi iskanje predal v VNet1, dokler mu zasnova tega ne dovoli. Dovoljenje je stikalo na peeringu, ki ga ima omrežje s prehodom.

Nastavite Allow gateway transit na peeringu VNet2 proti VNet1. Lastnost pripada objektu peeringa, ne sredstvu prehoda, zato jo berete in spreminjate v rezini peeringa. To je cela stran A.

Stran B: uporabite oddaljene prehode pri partnerju

Druga polovica je zrcalna slika: na peeringu VNet1 nazaj proti VNet2 omogočite Use remote gateways. Vklop iste zastavice na obeh koncih ali samo na enem pusti na pol zgrajeno pot in izvirni simptom nedotaknjen. Samo omrežje s prehodom VPN dovoljuje tranzit, partner pa je stran, ki ga uporablja.

Berite obe lastnosti na obeh omrežjih, namesto da bi zaupali rezini portala, ki ste jo nazadnje odprli.

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

Videti par drug ob drugem je najhitrejši način, da ujamete obrnjeno nastavitev. Peering, ki na strani prehoda poroča AllowGatewayTransit false, pojasni celotno okvaro brez zajemanja paketov.

Kaj mora odjemalec še prejeti

Usmerjanje je nujno in ne zadostuje, ker mora profil od točke do lokacije odjemalcu dati tudi naslov DNS, ki odgovori, ko tranzit deluje. Resolver platforme ni ta naslov: odgovarja na območja Azure Private DNS, povezana z virtualnim omrežjem, a nič za območje, gostovano na vaših lastnih imenikskih strežnikih, in to uporablja ta namestitev. Usmerite odjemalca tja in javna imena se veselo razrešijo, medtem ko notranji gostitelj ostane neznan.

Vprašajte resolver s povezanega prenosnega računalnika, preden spremenite karkoli drugega.

nslookup dc01.corp.example 10.1.0.4

Časovna omejitev pravi, da pot še manjka. Avtoritativni odgovor potisne težavo nazaj k odjemalcu, običajno pripono, ki se nikoli ne doda, zato kratka imena potujejo do javnega resolverja, ki jih veselo neuspešno razreši.

Primerjajte isto pogodbo na strani od lokacije do lokacije

Nič od tega ni posebej last prenosnih računalnikov. Zamenjajte odjemalca s podružnico na od lokacije do lokacije in dvostranska zahteva se vrne: podružnica pride neposredno v omrežje prehoda, storitev dve omrežji stran pa je še vedno za peeringom.

Tranzit je treba odobriti na obeh peeringih, stikalo, ki ga odobri, pa živi na peeringu in ne na vrsti odjemalca.

Preden okrivite prehod

Windows hrani seznam resolverjev za vsak vmesnik, zato potrdite, kaj je tunelski vmesnik dejansko prejel, preden okrivite prehod.

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

Negativen odgovor preživi popravek usmerjanja v predpomnilniku, zastarel seznam pripon pa še naprej pošilja poizvedbe nekam, kjer območje ni bilo nikoli gostovano. Počistite, vprašajte znova in zabeležite, kateri strežnik odgovori.

Dva manjša pogoja odločita, ali bo pot zdržala: naslovni prostori se ne smejo prekrivati, in skupina za omrežno varnost v podomrežju resolverja mora spustiti sklop odjemalcev, ki je le še en razpon virov. Dokažite to s preverjanjem učinkovitih poti s strani VM in eno neposredno poizvedbo z odjemalca, da se težava območja, težava pripone ali filter nikoli ne zamenjajo z manjkajočim tranzitom.

Sorodni članki