Azure P2S DNS zlyháva, keď je resolver v prepojenej VNet

Klient sa môže dostať do svojej vlastnej virtuálnej siete a napriek tomu nedokáže preložiť mená v prepojenej sieti. Prepojenie nie je tranzit brány, kým to obe strany nepovedia.

Pošlite ping na VM a tá odpovie; opýtajte sa na jej meno a klient povie, že hostiteľ je neznámy. Keď resolver sedí v prepojenej virtuálnej sieti namiesto tej, ktorá obsahuje bránu VPN, je táto dvojica výsledkov očakávaná a žiadne ladenie resolvera to nezmení. Chýba dohoda o smerovaní, ktorú prepojenie predvolene zadržiava. Dve topológie vyzerajú na papieri takmer rovnako a rozdiel medzi fungujúcou a pokazenou je dvojica prepínačov prepojenia nastavených správnym smerom.

Predstavte si notebook, ktorý tuneluje do brány vo VNet2, zatiaľ čo radič domény, ktorý slúži DNS, sedí vo VNet1.

Dve topológie, jeden rozdiel

Umiestnite resolver do vlastnej virtuálnej siete brány a meno sa preloží v okamihu, keď tunel naskočí. Žiadne nastavenie prepojenia sa na tomto vyhľadávaní nepodieľa.

Presuňte ten istý resolver za prepojenie a klient stále dostane odpoveď z VM, zatiaľ čo meno zostáva neznáme. Certifikát, tunel aj klient sú bez zmeny. Jediné, čo sa posunulo, je miesto, kde resolver žije. Prepojenie mu dalo trasu k tejto adrese, nie oprávnenie brány prenášať tam prevádzku.

Strana A: povoľte tranzit brány u vlastníka brány

Prepojenie spája dve virtuálne siete, ale spojenie nie je tranzitívne pre prevádzku, ktorá prichádza cez bránu, a požiadavka point-to-site prichádza presne tak. Brána vo VNet2 preto nemá oprávnenie odovzdať vyhľadávanie do VNet1, kým jej to návrh nedovolí. Povolením je prepínač na prepojení, ktoré vlastní sieť s bránou.

Nastavte Allow gateway transit na prepojení VNet2 smerom k VNet1. Vlastnosť patrí objektu prepojenia, nie prostriedku brány, takže ju čítate a meníte v okne prepojenia. To je celá strana A.

Strana B: použite vzdialené brány na partnerovi

Druhá polovica je zrkadlový obraz: na prepojení VNet1 späť k VNet2 zapnite Use remote gateways. Zapnutie tej istej príznaku na oboch koncoch, alebo len na jednom, necháva polovične postavenú cestu a pôvodný príznak nedotknutý. Tranzit povoľuje iba sieť s bránou VPN a partner je strana, ktorá ho používa.

Čítajte obe vlastnosti na oboch sieťach namiesto dôvery v okno portálu, ktoré ste naposledy otvorili.

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

Vidieť dvojicu vedľa seba je najrýchlejší spôsob, ako chytiť obrátené nastavenie. Prepojenie, ktoré na strane brány hlási AllowGatewayTransit false, vysvetľuje celé zlyhanie bez zachytávania paketov.

Čo musí klient stále dostať

Smerovanie je nutné, ale nie postačujúce, pretože profil point-to-site musí klientovi odovzdať aj adresu DNS, ktorá odpovedá, keď tranzit funguje. Platformový resolver nie je tou adresou: odpovedá na zóny Azure Private DNS prepojené s virtuálnou sieťou, ale nič pre zónu hostovanú na vašich vlastných adresárových serveroch, a to je to, čo toto nasadenie používa. Namierte klienta naň a verejné mená sa veselo preložia, zatiaľ čo interný hostiteľ zostane neznámy.

Opýtajte sa resolvera z pripojeného notebooku, než zmeníte čokoľvek iné.

nslookup dc01.corp.example 10.1.0.4

Časový limit hovorí, že cesta stále chýba. Autoritatívna odpoveď zatlačí problém späť na klienta, zvyčajne príponu, ktorá sa nikdy nepridá, takže krátke mená putujú k verejnému resolveru, ktorý ich veselo nechá zlyhať.

Porovnajte tú istú dohodu na strane site-to-site

Nič z toho nepatrí konkrétne notebookom. Vymeňte klienta za pobočku na site-to-site a dvojstranná požiadavka sa vracia: pobočka prichádza priamo do siete brány a služba o dve siete ďalej je stále za prepojením.

Tranzit musí byť povolený na oboch prepojeniach a prepínač, ktorý ho povoľuje, žije na prepojení, nie na type klienta.

Než obviníte bránu

Windows drží zoznam resolverov pre každý adaptér, takže potvrďte, čo tunelové rozhranie skutočne dostalo, než obviníte bránu.

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

Negatívna odpoveď prežije opravu smerovania v medzipamäti a zastaraný zoznam prípon ďalej posiela dotazy niekam, kde zóna nikdy nebola hostovaná. Vyčistite, opýtajte sa znova a poznačte, ktorý server odpovedá.

Dve menšie podmienky rozhodujú, či cesta vydrží: adresné priestory sa nesmú prekrývať, a skupina zabezpečenia siete v podsieti resolvera musí vpustiť klientsky fond, ktorý je len ďalším rozsahom zdrojov. Dokážte to kontrolou efektívnych trás zo strany VM plus jedným priamym dotazom z klienta, aby sa problém zóny, problém prípony alebo filter nikdy nezamenili s chýbajúcim tranzitom.

Súvisiace články