Azure P2S DNS neizdodas, ja resolver atrodas savienotā VNet

Klients var sasniegt savu virtuālo tīklu un tomēr nespēj atrisināt vārdus savienotā tīklā. Peering nav gateway tranzīts, kamēr abas puses to nepasaka.

Pingojiet VM, un tā atbild; pajautājiet tās vārdu, un klients saka, ka resursdators nav zināms. Kad resolver atrodas savienotā virtuālajā tīklā, nevis tajā, kurā ir VPN gateway, šis rezultātu pāris ir gaidāms, un neviens resolver diagnostikas apjoms to nemaina. Trūkst maršrutēšanas līguma, ko peering pēc noklusējuma aiztur. Divas topoloģijas uz papīra izskatās gandrīz identiskas, un starpība starp strādājošu un salauztu ir pāris peering slēdžu, kas novietoti pareizajā virzienā.

Iedomājieties portatīvo datoru, kas tuneļo uz gateway VNet2, kamēr DNS apkalpojošais domēna kontrolleris sēž VNet1.

Divas topoloģijas, viena atšķirība

Ievietojiet resolver paša gateway virtuālajā tīklā, un vārds tiek atrisināts tajā mirklī, kad tunelis paceļas. Neviena peering iestatījums šajā meklēšanā nepiedalās.

Pārvietojiet to pašu resolver pāri peering, un klients joprojām saņem atbildi no VM, kamēr vārds paliek nezināms. Sertifikāts, tunelis un klients nav mainījušies. Vienīgais, kas pārvietojās, ir tas, kur resolver dzīvo. Peering tam deva maršrutu uz šo adresi, nevis gateway pilnvaras tur nest satiksmi.

A puse: atļaujiet gateway tranzītu pie gateway īpašnieka

Peering savieno divus virtuālos tīklus, bet savienojums nav transitīvs satiksmei, kas ienāk caur gateway, un point-to-site pieprasījums ienāk tieši tā. Tāpēc VNet2 gateway nav pamata nodot meklēšanu VNet1, kamēr dizains to neļauj. Atļauja ir slēdzis uz peering, kas pieder tīklam ar gateway.

Iestatiet Allow gateway transit uz VNet2 peering pret VNet1. Šis rekvizīts pieder peering objektam, nevis gateway resursam, tāpēc to lasāt un maināt peering asmenī. Tā ir visa A puse.

B puse: izmantojiet attālos gateway partnera pusē

Otra puse ir spoguļattēls: uz VNet1 peering atpakaļ uz VNet2 iespējojiet Use remote gateways. Tā paša karodziņa ieslēgšana abos galos vai tikai vienā atstāj pusuzbūvētu ceļu un sākotnējo simptomu neskartu. Tikai tīkls ar VPN gateway atļauj tranzītu, un partneris ir tā puse, kas to izmanto.

Lasiet abus rekvizītus abos tīklos, nevis paļaujieties uz portāla asmeni, ko atvērāt pēdējo reizi.

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

Redzēt pāri blakus ir ātrākais veids, kā noķert apgrieztu iestatījumu. Peering, kas gateway pusē ziņo AllowGatewayTransit false, izskaidro visu kļūmi bez pakešu uztveršanas.

Kas klientam vēl jāsaņem

Maršrutēšana ir nepieciešama un nepietiekama, jo point-to-site profilam klientam jāpiešķir arī DNS adrese, kas atbild, kad tranzīts darbojas. Platformas resolver nav šī adrese: tas atbild uz ar virtuālo tīklu saistītajām Azure Private DNS zonām, bet neko par zonu, kas mitināta jūsu pašu direktorija serveros, un tieši to izmanto šī izvietošana. Novirziet klientu uz to, un publiskie vārdi priecīgi atrisināsies, kamēr iekšējais resursdators paliek nezināms.

Pajautājiet resolver no pievienotā portatīvā datora, pirms kaut ko citu maināt.

nslookup dc01.corp.example 10.1.0.4

Taimauts saka, ka ceļa vēl nav. Autoritatīva atbilde atgrūž problēmu atpakaļ klientam, parasti sufikss, kas nekad netiek pievienots, tāpēc īsie vārdi ceļo uz publisku resolver, kas tos priecīgi izgāž.

Salīdziniet to pašu līgumu site-to-site pusē

Nekas no tā nepieder tieši portatīvajiem datoriem. Aizstājiet klientu ar site-to-site filiāli, un abpusējā prasība atgriežas: filiāle ierodas tieši gateway tīklā, un pakalpojums divu tīklu attālumā joprojām ir aiz peering.

Tranzīts jāpiešķir abos peering, un slēdzis, kas to piešķir, atrodas uz peering, nevis uz klienta tipa.

Pirms vainojat gateway

Windows glabā resolver sarakstu katram adapterim, tāpēc apstipriniet, ko tuneļa saskarne faktiski saņēma, pirms vainojat gateway.

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

Negatīva atbilde kešatmiņā pārdzīvo maršrutēšanas labojumu, un novecojis sufiksu saraksts turpina sūtīt vaicājumus uz vietu, kur zona nekad nav mitināta. Notīriet, pajautājiet vēlreiz un pierakstiet, kurš serveris atbild.

Divi mazāki nosacījumi izšķir, vai ceļš noturēsies: adrešu telpas nedrīkst pārklāties, un tīkla drošības grupai resolver apakštīklā ir jāielaiž klientu pūls, kas ir tikai vēl viens avota diapazons. Pierādiet to ar efektīvo maršrutu pārbaudi no VM puses un vienu tiešu vaicājumu no klienta, lai zonas problēma, sufiksa problēma vai filtrs nekad netiktu sajaukts ar trūkstošu tranzītu.

Saistītie raksti