Il DNS di Azure P2S fallisce quando il resolver è in una VNet con peering

Fai ping alla VM e risponde; chiedi il suo nome e il client dice che l'host è sconosciuto. Quando il resolver si trova in una rete virtuale con peering invece che in quella che contiene il gateway VPN, quella coppia di risultati è attesa, e nessuna quantità di diagnostica del resolver la cambia. Ciò che manca è un contratto di routing che il peering trattiene per impostazione predefinita. Due topologie sembrano quasi identiche sulla carta, e il divario tra funzionante e rotto è una coppia di interruttori di peering impostati nel verso giusto.

Immagina un portatile che incanala un tunnel verso un gateway in VNet2, mentre il controller di dominio che serve il DNS siede in VNet1.

Due topologie, una differenza

Metti il resolver dentro la rete virtuale del gateway stesso e il nome si risolve nel momento in cui il tunnel sale. Nessuna impostazione di peering partecipa a quella ricerca.

Sposta lo stesso resolver oltre un peering e il client riceve ancora una risposta dalla VM mentre il nome resta sconosciuto. Certificato, tunnel e client sono invariati. L'unica cosa che si è spostata è dove vive il resolver. Il peering gli ha dato una rotta verso quell'indirizzo, non l'autorità al gateway di portarvi traffico.

Lato A: consenti il transito del gateway sul proprietario del gateway

Un peering unisce due reti virtuali, ma l'unione non è transitiva per il traffico che arriva attraverso un gateway, e una richiesta point-to-site arriva esattamente così. Il gateway in VNet2 non ha quindi titolo per consegnare la ricerca a VNet1 finché il progetto non glielo concede. Il permesso è un interruttore sul peering posseduto dalla rete che contiene il gateway.

Imposta Allow gateway transit sul peering di VNet2 verso VNet1. La proprietà appartiene all'oggetto peering, non alla risorsa gateway, quindi la leggi e la modifichi nel pannello del peering. Questo è tutto il lato A.

Lato B: usa gateway remoti sul peer

L'altra metà è l'immagine speculare: sul peering di VNet1 di ritorno a VNet2, abilita Use remote gateways. Accendere lo stesso flag su entrambe le estremità, o solo su una, lascia un percorso a metà e il sintomo originale intatto. Solo la rete con il gateway VPN consente il transito, e il peer è il lato che lo usa.

Leggi entrambe le proprietà su entrambe le reti invece di fidarti del pannello del portale che hai aperto per ultimo.

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

Vedere la coppia fianco a fianco è il modo più rapido per cogliere un'impostazione invertita. Un peering che riporta AllowGatewayTransit false sul lato del gateway spiega l'intero guasto senza catturare pacchetti.

Cosa deve ancora ricevere il client

Il routing è necessario e non sufficiente, perché il profilo point-to-site deve anche consegnare al client un indirizzo DNS che risponda una volta che il transito funziona. Il resolver della piattaforma non è quell'indirizzo: risponde per le zone Azure Private DNS collegate alla rete virtuale, ma nulla per una zona ospitata sui tuoi server di directory, ed è quello che usa questa distribuzione. Punta un client su di esso e i nomi pubblici si risolvono allegramente mentre l'host interno resta sconosciuto.

Interroga il resolver dal portatile connesso prima di cambiare qualsiasi altra cosa.

nslookup dc01.corp.example 10.1.0.4

Un timeout dice che il percorso manca ancora. Una risposta autorevole rimanda il problema al client, di solito un suffisso che non viene mai aggiunto, così i nomi brevi viaggiano verso un resolver pubblico che li fa fallire allegramente.

Confronta lo stesso contratto sul lato site-to-site

Niente di tutto questo appartiene specificamente ai portatili. Sostituisci il client con una filiale in site-to-site e il requisito a due lati ritorna: la filiale arriva direttamente nella rete del gateway, e un servizio a due reti di distanza è ancora dietro il peering.

Il transito deve essere concesso su entrambi i peering, e l'interruttore che lo concede vive sul peering e non sul tipo di client.

Prima di dare la colpa al gateway

Windows tiene un elenco di resolver per adattatore, quindi conferma cosa ha ricevuto davvero l'interfaccia del tunnel prima di dare la colpa al gateway.

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

Una risposta negativa sopravvive alla correzione del routing nella cache, e un elenco di suffissi obsoleto continua a inviare query dove la zona non è mai stata ospitata. Svuota, chiedi di nuovo e annota quale server risponde.

Due condizioni più piccole decidono se il percorso regge: gli spazi degli indirizzi non devono sovrapporsi, e il gruppo di sicurezza di rete nella sottorete del resolver deve ammettere il pool di client, che è solo un altro intervallo di origine. Provalo con un controllo delle rotte effettive dal lato VM più una query diretta dal client, così che un problema di zona, un problema di suffisso o un filtro non vengano mai scambiati per transito mancante.