Azure P2S-DNS misluk wanneer die resolver in 'n peerde VNet is

'n Kliënt kan sy eie virtuele netwerk bereik en steeds faal om name in 'n peerde netwerk op te los. Peering is nie gateway-deurgang voordat beide kante dit sê nie.

Ping die VM en dit antwoord; vra sy naam en die kliënt sê die gasheer is onbekend. Wanneer die resolver in 'n peerde virtuele netwerk sit eerder as in die een wat die VPN-gateway huisves, is daardie paar resultate verwag, en geen hoeveelheid resolver-ontfouting verander dit nie. Wat ontbreek, is 'n roeteringskontrak wat peering by verstek weerhou. Twee topologieë lyk byna identies op papier, en die gaping tussen werkend en stukkend is 'n paar peering-skakelaars wat reg om gesit is.

Stel jou 'n skootrekenaar voor wat in 'n gateway in VNet2 intunnel, met die domeinbeheerder wat DNS dien in VNet1.

Twee topologieë, een verskil

Plaas die resolver binne die gateway se eie virtuele netwerk en die naam los op sodra die tonnel opkom. Geen peering-instelling neem aan daardie opsoek deel nie.

Skuif dieselfde resolver oor 'n peering en die kliënt kry steeds 'n antwoord van die VM terwyl die naam onbekend bly. Sertifikaat, tonnel en kliënt is onveranderd. Die enigste ding wat geskuif het, is waar die resolver woon. Peering het dit 'n roete na daardie adres gegee, nie gesag vir die gateway om verkeer daarheen te dra nie.

Kant A: laat gateway-deurgang toe op die gateway-eienaar

'n Peering verbind twee virtuele netwerke, maar die verbinding is nie transitief vir verkeer wat deur 'n gateway aankom nie, en 'n punt-tot-punt-versoek kom presies so aan. Die gateway in VNet2 het dus geen standing om die opsoek aan VNet1 oor te hand nie voordat die ontwerp dit toestaan nie. Die toestemming is 'n skakelaar op die peering wat deur die netwerk besit word wat die gateway huisves.

Stel Allow gateway transit op VNet2 se peering na VNet1. Die eienskap behoort aan die peering-objek, nie aan die gateway-hulpbron nie, so die peering-blad is waar jy dit lees en verander. Dit is die hele kant A.

Kant B: gebruik afgeleë gateways op die eweknie

Die ander helfte is die spieëlbeeld: op VNet1 se peering terug na VNet2, aktiveer Use remote gateways. Om dieselfde vlag aan beide kante, of net aan een kant, aan te skakel, laat 'n halfgeboude pad en die oorspronklike simptoom onaangeraak. Net die netwerk met die VPN-gateway laat deurgang toe, en die eweknie is die kant wat dit gebruik.

Lees beide eienskappe op beide netwerke in plaas daarvan om die portaalblad te vertrou wat jy laas oopgemaak het.

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

Om die paar langs mekaar te sien, is die vinnigste manier om 'n omgekeerde instelling te vang. 'n Peering wat AllowGatewayTransit false aan die gateway-kant rapporteer, verduidelik die hele faling sonder 'n pakkie-opname.

Wat die kliënt steeds moet ontvang

Roetering is nodig en nie voldoende nie, want die punt-tot-punt-profiel moet ook 'n DNS-adres aan die kliënt gee wat antwoord sodra deurgang werk. Die platform-resolver is nie daardie adres nie: dit antwoord Azure Private DNS-sones wat aan die virtuele netwerk gekoppel is, maar niks vir 'n sone wat op jou eie gidsbedieners gehuisves word nie, en dit is wat hierdie ontplooiing gebruik. Wys 'n kliënt daarheen en openbare name los geredelik op terwyl die interne gasheer onbekend bly.

Vra die resolver uit vanaf die gekoppelde skootrekenaar voordat jy enigiets anders verander.

nslookup dc01.corp.example 10.1.0.4

'n Tydverstreke antwoord sê die pad ontbreek steeds. 'n Gesaghebbende antwoord stoot die probleem terug na die kliënt, gewoonlik 'n agtervoegsel wat nooit aangeheg word nie, so kort name reis na 'n openbare resolver wat hulle geredelik laat misluk.

Vergelyk dieselfde kontrak aan die werf-tot-werf-kant

Niks hiervan hoort spesifiek aan skootrekenaars nie. Ruil die kliënt vir 'n tak op werf-tot-werf en die tweesydige vereiste keer terug: die tak kom direk by die gateway-netwerk aan, en 'n diens twee netwerke weg is steeds agter die peering.

Deurgang moet by beide peerings toegestaan word, en die skakelaar wat dit toestaan, woon op die peering eerder as op die kliënttipe.

Voordat jy die gateway blameer

Windows hou 'n resolver-lys per adapter, so bevestig wat die tonnel-koppelvlak werklik ontvang het voordat jy die gateway blameer.

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

'n Negatiewe antwoord oorleef die roeteringsherstel in die kas, en 'n verouderde agtervoegsel-lys hou aan om navrae na iets te stuur wat nooit die sone gehuisves het nie. Spoel, vra weer, en let op watter bediener antwoord.

Twee kleiner voorwaardes besluit of die pad hou: die adresruimtes mag nie oorvleuel nie, en die netwerksekuriteitsgroep op die resolver se subnet moet die kliëntpoel toelaat, wat net nog 'n bronreeks is. Bewys dit met 'n effektiewe-roete-kontrole vanaf die VM-kant plus een direkte navraag van die kliënt, sodat 'n sone-probleem, 'n agtervoegsel-probleem of 'n filter nooit vir ontbrekende deurgang aangesien word nie.

Verwante artikels