Azure P2S DNS се проваля, когато резолверът е в пиъринг VNet

Клиентът може да достигне собствената си виртуална мрежа и пак да не резолвва имена в пиъринг мрежа. Пиърингът не е транзит на шлюз, докато двете страни не го разрешат.

Пингнете VM и тя отговаря; попитайте за името ѝ и клиентът казва, че хостът е неизвестен. Когато резолверът е в пиъринг виртуална мрежа, а не в тази, която държи VPN шлюза, тази двойка резултати е очаквана и никакво отстраняване на проблеми с резолвера не я променя. Липсва договор за маршрутизация, който пиърингът задържа по подразбиране. Две топологии изглеждат почти еднакво на хартия, а разликата между работеща и счупена е чифт превключватели на пиъринга, поставени в правилната посока.

Представете си лаптоп, който тунелира към шлюз във VNet2, а контролерът на домейна, който обслужва DNS, седи във VNet1.

Две топологии, една разлика

Поставете резолвера в собствената виртуална мрежа на шлюза и името се резолвва в момента, в който тунелът се вдигне. Никаква настройка на пиъринга не участва в това търсене.

Преместете същия резолвер отвъд пиъринг и клиентът пак получава отговор от VM, докато името остава неизвестно. Сертификатът, тунелът и клиентът не са се променили. Единственото, което се премести, е къде живее резолверът. Пиърингът му даде маршрут до този адрес, а не право на шлюза да носи трафик там.

Страна A: разрешете транзит на шлюз при собственика на шлюза

Пиърингът свързва две виртуални мрежи, но връзката не е транзитивна за трафик, който пристига през шлюз, а заявката точка-към-сайт пристига точно така. Затова шлюзът във VNet2 няма основание да предаде търсенето на VNet1, докато дизайнът не го разреши. Разрешението е превключвател върху пиъринга, собственост на мрежата, която държи шлюза.

Задайте Allow gateway transit върху пиъринга на VNet2 към VNet1. Свойството принадлежи на обекта пиъринг, а не на ресурса шлюз, затова го четете и променяте в листа на пиъринга. Това е цялата страна A.

Страна B: използвайте отдалечени шлюзове на партньора

Другата половина е огледален образ: върху пиъринга на VNet1 обратно към VNet2 включете Use remote gateways. Включването на същия флаг в двата края или само в единия оставя полуизграден път и първоначалния симптом непроменен. Само мрежата с VPN шлюза разрешава транзит, а партньорът е страната, която го използва.

Четете двете свойства на двете мрежи, вместо да се доверявате на листа на портала, който отворихте последно.

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

Виждането на двойката едно до друго е най-бързият начин да хванете обърната настройка. Пиъринг, който показва AllowGatewayTransit false от страната на шлюза, обяснява целия провал без прихващане на пакети.

Какво клиентът все още трябва да получи

Маршрутизацията е необходима, но не достатъчна, защото профилът точка-към-сайт също трябва да даде на клиента DNS адрес, който отговаря, след като транзитът работи. Платформеният резолвер не е този адрес: той отговаря за зони на Azure Private DNS, свързани с виртуалната мрежа, но нищо за зона, хоствана на вашите собствени сървъри за директория, а точно това използва това внедряване. Насочете клиент към него и публичните имена се резолвват весело, докато вътрешният хост остава неизвестен.

Попитайте резолвера от свързания лаптоп, преди да промените нещо друго.

nslookup dc01.corp.example 10.1.0.4

Изтичане на времето казва, че пътят все още липсва. Авторитетен отговор връща проблема към клиента, обикновено суфикс, който никога не се добавя, така че кратките имена отиват при публичен резолвер, който ги проваля весело.

Сравнете същия договор от страната сайт-към-сайт

Нищо от това не принадлежи конкретно на лаптопите. Сменете клиента с клон сайт-към-сайт и двустранното изискване се връща: клонът пристига директно в мрежата на шлюза, а услуга на две мрежи разстояние все още е зад пиъринга.

Транзитът трябва да бъде разрешен на двата пиъринга, а превключвателят, който го разрешава, живее на пиъринга, а не на типа клиент.

Преди да обвините шлюза

Windows пази списък с резолвери за всеки адаптер, затова потвърдете какво наистина е получил тунелният интерфейс, преди да обвините шлюза.

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

Отрицателен отговор преживява поправката на маршрутизацията в кеша, а остарял списък със суфикси продължава да праща заявки някъде, където зоната никога не е била хоствана. Изчистете, попитайте отново и отбележете кой сървър отговаря.

Две по-малки условия решават дали пътят ще се задържи: адресните пространства не трябва да се припокриват, а групата за мрежова сигурност в подмрежата на резолвера трябва да допуска клиентския пул, който е просто още един диапазон източници. Докажете го с проверка на ефективните маршрути от страната на VM плюс една директна заявка от клиента, така че проблем със зона, проблем със суфикс или филтър никога да не бъдат сбъркани с липсващ транзит.

Подобни статии