El DNS d'Azure P2S falla quan el resolutor és en una VNet aparellada

Feu ping a la VM i respon; pregunteu-li el nom i el client diu que l'amfitrió és desconegut. Quan el resolutor és en una xarxa virtual aparellada en lloc de la que conté la passarel·la VPN, aquest parell de resultats és l'esperat, i cap quantitat de diagnòstic del resolutor ho canvia. El que falta és un contracte d'encaminament que l'aparellament reté per defecte. Dues topologies semblen gairebé idèntiques sobre el paper, i la diferència entre funcionar i fallar és un parell d'interruptors d'aparellament posats en la direcció correcta.

Imagineu un portàtil que tunelitza cap a una passarel·la a VNet2, amb el controlador de domini que serveix DNS a VNet1.

Dues topologies, una diferència

Poseu el resolutor dins de la mateixa xarxa virtual de la passarel·la i el nom es resol en el moment que el túnel s'aixeca. Cap paràmetre d'aparellament no intervé en aquesta consulta.

Moveu el mateix resolutor a l'altra banda d'un aparellament i el client encara rep una resposta de la VM mentre el nom continua desconegut. El certificat, el túnel i el client no han canviat. L'única cosa que s'ha mogut és on viu el resolutor. L'aparellament li va donar una ruta cap a aquella adreça, no autoritat a la passarel·la per portar-hi trànsit.

Banda A: permeteu el trànsit de passarel·la al propietari de la passarel·la

Un aparellament uneix dues xarxes virtuals, però la unió no és transitiva per al trànsit que arriba per una passarel·la, i una sol·licitud punt a lloc arriba exactament així. La passarel·la a VNet2 no té, doncs, cap facultat per lliurar la consulta a VNet1 fins que el disseny ho concedeixi. La concessió és un interruptor a l'aparellament que posseeix la xarxa que conté la passarel·la.

Definiu Allow gateway transit a l'aparellament de VNet2 cap a VNet1. La propietat pertany a l'objecte d'aparellament, no al recurs de passarel·la, així que la llegiu i la canvieu a la fulla d'aparellament. Aquesta és tota la banda A.

Banda B: useu passarel·les remotes al parell

L'altra meitat és la imatge mirall: a l'aparellament de VNet1 de tornada a VNet2, activeu Use remote gateways. Activar la mateixa marca als dos extrems, o només a un, deixa un camí mig construït i el símptoma original intacte. Només la xarxa amb la passarel·la VPN permet el trànsit, i el parell és la banda que el fa servir.

Llegiu les dues propietats a les dues xarxes en lloc de confiar en la fulla del portal que vau obrir l'última vegada.

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

Veure el parell costat a costat és la manera més ràpida de caçar un paràmetre invertit. Un aparellament que informa AllowGatewayTransit false a la banda de la passarel·la explica tota la fallada sense capturar cap paquet.

Què ha de rebre encara el client

L'encaminament és necessari i no suficient, perquè el perfil punt a lloc també ha de lliurar al client una adreça DNS que respongui quan el trànsit funcioni. El resolutor de la plataforma no és aquesta adreça: respon les zones d'Azure Private DNS vinculades a la xarxa virtual, però res per a una zona allotjada als vostres propis servidors de directori, que és el que fa servir aquest desplegament. Apunteu-hi un client i els noms públics es resolen alegrement mentre l'amfitrió intern continua desconegut.

Consulteu el resolutor des del portàtil connectat abans de canviar res més.

nslookup dc01.corp.example 10.1.0.4

Un temps d'espera diu que el camí encara falta. Una resposta autoritativa torna el problema al client, normalment un sufix que mai s'afegeix, de manera que els noms curts viatgen cap a un resolutor públic que els falla alegrement.

Compareu el mateix contracte a la banda de lloc a lloc

Res d'això no és propi dels portàtils. Canvieu el client per una sucursal de lloc a lloc i el requisit de dues bandes torna: la sucursal arriba directament a la xarxa de la passarel·la, i un servei a dues xarxes de distància continua darrere de l'aparellament.

El trànsit s'ha de concedir als dos aparellaments, i l'interruptor que el concedeix viu a l'aparellament, no al tipus de client.

Abans de culpar la passarel·la

Windows manté una llista de resolutors per adaptador, així que confirmeu què ha rebut realment la interfície del túnel abans de culpar la passarel·la.

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

Una resposta negativa sobreviu a l'arranjament de l'encaminament a la memòria cau, i una llista de sufixos obsoleta continua enviant consultes a un lloc que mai no va allotjar la zona. Buideu, torneu a preguntar i anoteu quin servidor respon.

Dues condicions més petites decideixen si el camí aguanta: els espais d'adreces no es poden solapar, i el grup de seguretat de xarxa a la subxarxa del resolutor ha d'admetre el pool de clients, que és només un altre interval d'origen. Demostreu-ho amb una comprovació de rutes efectives des de la banda de la VM més una consulta directa des del client, perquè un problema de zona, un problema de sufix o un filtre no es confonguin mai amb un trànsit absent.