Azure P2S DNS selhává, když je resolver v propojené VNet

Klient může dosáhnout své vlastní virtuální sítě, a přesto nedokáže přeložit jména v propojené síti. Propojení není tranzit brány, dokud to obě strany nedovolí.

Pošlete ping na VM a ta odpoví; zeptejte se na její jméno a klient řekne, že hostitel je neznámý. Když resolver sedí v propojené virtuální síti místo v té, která drží bránu VPN, je tato dvojice výsledků očekávaná a žádné ladění resolveru to nezmění. Chybí smluvní ujednání o směrování, které propojení ve výchozím nastavení zadržuje. Dvě topologie vypadají na papíře téměř stejně a rozdíl mezi fungující a rozbitou je dvojice přepínačů propojení nastavených správným směrem.

Představte si notebook, který tuneluje do brány ve VNet2, zatímco řadič domény, který slouží DNS, sedí ve VNet1.

Dvě topologie, jeden rozdíl

Umístěte resolver do vlastní virtuální sítě brány a jméno se přeloží ve chvíli, kdy tunel naskočí. Žádné nastavení propojení se na tomto vyhledávání nepodílí.

Přesuňte stejný resolver za propojení a klient stále dostane odpověď z VM, zatímco jméno zůstává neznámé. Certifikát, tunel i klient jsou beze změny. Jediné, co se posunulo, je místo, kde resolver žije. Propojení mu dalo trasu k této adrese, ne oprávnění brány přenášet tam provoz.

Strana A: povolte tranzit brány u vlastníka brány

Propojení spojuje dvě virtuální sítě, ale spojení není tranzitivní pro provoz, který přichází přes bránu, a požadavek point-to-site přichází právě tak. Brána ve VNet2 proto nemá oprávnění předat vyhledávání do VNet1, dokud jí to návrh nedovolí. Povolení je přepínač na propojení, které vlastní síť s bránou.

Nastavte Allow gateway transit na propojení VNet2 směrem k VNet1. Vlastnost patří objektu propojení, ne prostředku brány, takže ji čtete a měníte v okně propojení. To je celá strana A.

Strana B: použijte vzdálené brány na protějšku

Druhá polovina je zrcadlový obraz: na propojení VNet1 zpět k VNet2 zapněte Use remote gateways. Zapnutí stejného příznaku na obou koncích, nebo jen na jednom, ponechá polovičně postavenou cestu a původní příznak nedotčený. Tranzit povoluje pouze síť s bránou VPN a protějšek je strana, která ho používá.

Čtěte obě vlastnosti na obou sítích, místo abyste věřili oknu portálu, které jste naposledy otevřeli.

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

Vidět dvojici vedle sebe je nejrychlejší způsob, jak chytit obrácené nastavení. Propojení, které hlásí AllowGatewayTransit false na straně brány, vysvětluje celé selhání bez zachytávání paketů.

Co musí klient stále dostat

Směrování je nutné, ale ne dostačující, protože profil point-to-site musí klientovi předat také adresu DNS, která odpovídá, jakmile tranzit funguje. Platformní resolver není touto adresou: odpovídá na zóny Azure Private DNS propojené s virtuální sítí, ale nic pro zónu hostovanou na vašich vlastních adresářových serverech, a to je to, co toto nasazení používá. Namiřte klienta na něj a veřejná jména se vesele přeloží, zatímco interní hostitel zůstane neznámý.

Zeptejte se resolveru z připojeného notebooku, než změníte cokoli jiného.

nslookup dc01.corp.example 10.1.0.4

Časový limit říká, že cesta stále chybí. Autoritativní odpověď vrací problém klientovi, obvykle sufix, který se nikdy nepřipojí, takže krátká jména putují k veřejnému resolveru, který je vesele odmítá.

Porovnejte stejné ujednání na straně site-to-site

Nic z toho nepatří konkrétně notebookům. Vyměňte klienta za pobočku na site-to-site a dvoustranný požadavek se vrací: pobočka přichází přímo do sítě brány a služba o dvě sítě dál je stále za propojením.

Tranzit musí být povolen na obou propojeních a přepínač, který ho povoluje, žije na propojení, nikoli na typu klienta.

Než obviníte bránu

Windows drží seznam resolverů pro každý adaptér, takže potvrďte, co tunelové rozhraní skutečně dostalo, než obviníte bránu.

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

Negativní odpověď přežije opravu směrování v mezipaměti a zastaralý seznam sufixů dál posílá dotazy někam, kde zóna nikdy nebyla hostována. Vyčistěte mezipaměť, zeptejte se znovu a poznamenejte, který server odpovídá.

Dvě menší podmínky rozhodují, zda cesta vydrží: adresní prostory se nesmějí překrývat, a skupina zabezpečení sítě v podsíti resolveru musí pustit klientský fond, což je jen další rozsah zdrojů. Dokažte to kontrolou efektivních tras ze strany VM plus jedním přímým dotazem z klienta, aby se problém zóny, problém sufixu nebo filtr nikdy nespletly s chybějícím tranzitem.

Související články