DNS-ul Azure P2S eșuează când resolverul este într-un VNet împerecheat

Trimiteți ping la VM și aceasta răspunde; întrebați-i numele și clientul spune că gazda este necunoscută. Când resolverul se află într-o rețea virtuală împerecheată, nu în cea care conține gateway-ul VPN, această pereche de rezultate este de așteptat, iar niciun efort de diagnosticare a resolverului nu o schimbă. Ce lipsește este un contract de rutare pe care împerecherea îl reține implicit. Două topologii arată aproape identic pe hârtie, iar diferența dintre funcțional și defect este o pereche de comutatoare de împerechere puse în direcția corectă.

Imaginați-vă un laptop care tunelează într-un gateway din VNet2, în timp ce controlerul de domeniu care servește DNS stă în VNet1.

Două topologii, o diferență

Puneți resolverul în propria rețea virtuală a gateway-ului și numele se rezolvă în momentul în care tunelul urcă. Nicio setare de împerechere nu participă la acea căutare.

Mutați același resolver dincolo de o împerechere și clientul primește în continuare răspuns de la VM, în timp ce numele rămâne necunoscut. Certificatul, tunelul și clientul sunt neschimbate. Singurul lucru care s-a mișcat este unde locuiește resolverul. Împerecherea i-a dat o rută către acea adresă, nu autoritate gateway-ului de a duce trafic acolo.

Partea A: permiteți tranzitul gateway-ului la proprietarul gateway-ului

O împerechere unește două rețele virtuale, dar legătura nu este tranzitivă pentru traficul care sosește printr-un gateway, iar o cerere punct-la-site sosește exact așa. Gateway-ul din VNet2 nu are deci temei să predea căutarea către VNet1 până când proiectul nu îi permite. Permisiunea este un comutator pe împerecherea deținută de rețeaua care conține gateway-ul.

Setați Allow gateway transit pe împerecherea VNet2 spre VNet1. Proprietatea aparține obiectului de împerechere, nu resursei gateway, așa că o citiți și o modificați în lama de împerechere. Asta este toată partea A.

Partea B: folosiți gateway-uri la distanță pe pereche

Cealaltă jumătate este imaginea în oglindă: pe împerecherea VNet1 înapoi spre VNet2, activați Use remote gateways. Activarea aceluiași indicator la ambele capete, sau doar la unul, lasă o cale pe jumătate construită și simptomul original neatins. Doar rețeaua cu gateway-ul VPN permite tranzitul, iar perechea este partea care îl folosește.

Citiți ambele proprietăți pe ambele rețele în loc să aveți încredere în lama de portal deschisă ultima dată.

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

Vederea perechii una lângă alta este cea mai rapidă cale de a prinde o setare inversată. O împerechere care raportează AllowGatewayTransit false pe partea gateway-ului explică întreaga defecțiune fără captură de pachete.

Ce trebuie să mai primească clientul

Rutarea este necesară și nu suficientă, pentru că profilul punct-la-site trebuie să dea clientului și o adresă DNS care răspunde după ce tranzitul funcționează. Resolverul platformei nu este acea adresă: răspunde pentru zonele Azure Private DNS legate de rețeaua virtuală, dar nimic pentru o zonă găzduită pe serverele dumneavoastră de director, iar asta folosește această implementare. Îndreptați un client spre el și numele publice se rezolvă voioase, în timp ce gazda internă rămâne necunoscută.

Întrebați resolverul de pe laptopul conectat înainte de a schimba orice altceva.

nslookup dc01.corp.example 10.1.0.4

Un timeout spune că calea încă lipsește. Un răspuns autoritativ împinge problema înapoi la client, de obicei un sufix care nu este niciodată adăugat, așa că numele scurte călătoresc către un resolver public care le eșuează voios.

Comparați același contract pe partea site-la-site

Nimic din toate acestea nu aparține în mod special laptopurilor. Înlocuiți clientul cu o sucursală în site-la-site și cerința bilaterală revine: sucursala ajunge direct în rețeaua gateway-ului, iar un serviciu la două rețele distanță este încă în spatele împerecherii.

Tranzitul trebuie acordat pe ambele împerechei, iar comutatorul care îl acordă stă pe împerechere, nu pe tipul de client.

Înainte să dați vina pe gateway

Windows ține o listă de resolvere pentru fiecare adaptor, așa că confirmați ce a primit de fapt interfața tunelului înainte să dați vina pe gateway.

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

Un răspuns negativ supraviețuiește corecției de rutare din cache, iar o listă de sufixe învechită continuă să trimită interogări acolo unde zona nu a fost niciodată găzduită. Goliți, întrebați din nou și notați care server răspunde.

Două condiții mai mici decid dacă calea rezistă: spațiile de adrese nu trebuie să se suprapună, iar grupul de securitate de rețea din subrețeaua resolverului trebuie să admită pool-ul de clienți, care este doar un alt interval de sursă. Demonstrați-o cu o verificare a rutelor efective din partea VM plus o interogare directă din client, astfel încât o problemă de zonă, o problemă de sufix sau un filtru să nu fie niciodată confundate cu tranzitul lipsă.