Azure P2S DNS сәтсіз аяқталады, егер resolver теңшелінген VNet ішінде болса

Клиент өз виртуалды желісіне жете алады, бірақ теңшелінген желідегі атауларды шеше алмайды. Peering — екі жақ келіскенге дейін gateway транзиті емес.

VM-ге ping жіберіңіз — ол жауап береді; атын сұраңыз — клиент хост белгісіз деп айтады. Resolver VPN gateway бар желіде емес, теңшелінген виртуалды желіде орналасқанда, бұл екі нәтиже күтілетін жағдай, және resolver-ді қанша тексерсеңіз де ол өзгермейді. Жетіспейтіні — peering әдепкі бойынша ұстап тұратын маршруттау шарты. Екі топология қағазда бірдей дерлік көрінеді, ал жұмыс істейтін мен бұзылғанның арасындағы айырма — дұрыс бағытта қойылған бір жұп peering ауыстырып-қосқышы.

Ноутбук VNet2-дегі gateway-ге туннель жасап, DNS қызметін көрсететін домен контроллері VNet1-де отыр деп елестетіңіз.

Екі топология, бір айырма

Resolver-ді gateway-дің өз виртуалды желісіне қойыңыз — туннель көтерілген сәтте атау шешіледі. Бұл іздеуге ешбір peering параметрі қатыспайды.

Сол resolver-ді peering арқылы арғы жаққа жылжытыңыз — клиент әлі де VM-нен жауап алады, ал атау белгісіз күйінде қалады. Сертификат, туннель және клиент өзгерген жоқ. Жылжыған жалғыз нәрсе — resolver қайда тұратыны. Peering оған сол мекенжайға маршрут берді, gateway-ге ол жаққа трафик тасымалдау құқығын емес.

A жағы: gateway иесінде gateway транзитіне рұқсат беріңіз

Peering екі виртуалды желіні біріктіреді, бірақ бұл бірігу gateway арқылы келетін трафик үшін транзиттік емес, ал point-to-site сұранысы дәл солай келеді. Сондықтан VNet2-дегі gateway дизайн рұқсат бермейінше іздеуді VNet1-ге тапсыруға құқылы емес. Рұқсат — gateway-ді ұстап тұрған желіге тиесілі peering-дегі ауыстырып-қосқыш.

VNet2-ден VNet1-ге қарай peering-де Allow gateway transit қойыңыз. Бұл қасиет gateway ресурсына емес, peering нысанына тиесілі, сондықтан оны peering blade-інде оқып, өзгертесіз. A жағы толығымен осы.

B жағы: серіктесте қашықтағы gateway-лерді пайдаланыңыз

Екінші жартысы — айна бейнесі: VNet1-ден VNet2-ге қайтатын peering-де Use remote gateways қосыңыз. Сол флагты екі ұшта да, немесе тек бір ұшта қосу жартылай салынған жолды және бастапқы белгіні қозғалмай қалдырады. Тек VPN gateway бар желі транзитке рұқсат береді, ал серіктес — оны пайдаланатын жақ.

Соңғы ашқан портал blade-іне сенудің орнына екі желіде екі қасиетті де оқыңыз.

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

Жұпты қатар көру — кері қойылған параметрді ұстап алудың ең жылдам жолы. Gateway жағында AllowGatewayTransit false деп хабарлайтын peering бүкіл ақауды пакет ұстамай-ақ түсіндіреді.

Клиент әлі де не алуы керек

Маршруттау қажет, бірақ жеткіліксіз, өйткені point-to-site профилі клиентке транзит жұмыс істеген соң жауап беретін DNS мекенжайын да беруі керек. Платформа resolver-і ол мекенжай емес: ол виртуалды желіге байланыстырылған Azure Private DNS аймақтарына жауап береді, бірақ өз каталог серверлеріңізде орналасқан аймаққа ештеңе қайтармайды, ал бұл орналастыру дәл соны пайдаланады. Клиентті соған бағыттасаңыз, жария атаулар көңілді шешіледі, ішкі хост белгісіз күйінде қалады.

Басқаны өзгертуден бұрын қосылған ноутбуктен resolver-ге сұраныс жіберіңіз.

nslookup dc01.corp.example 10.1.0.4

Тайм-аут жол әлі жетіспейтінін айтады. Өкілетті жауап мәселені клиентке қайтарады, әдетте ешқашан қосылмайтын жұрнақ, сондықтан қысқа атаулар оларды көңілді сәтсіз ететін жария resolver-ге жол тартады.

Сол шартты site-to-site жағында салыстырыңыз

Бұның ешқайсысы ноутбуктерге ғана тән емес. Клиентті site-to-site филиалына ауыстырыңыз — екі жақты талап қайта оралады: филиал gateway желісіне тікелей келеді, ал екі желі қашықтықтағы қызмет әлі де peering артында.

Транзит екі peering-де де берілуі керек, ал оны беретін ауыстырып-қосқыш клиент түрінде емес, peering-де тұрады.

Gateway-ді кінәламас бұрын

Windows әр адаптер үшін resolver тізімін ұстайды, сондықтан gateway-ді кінәламас бұрын туннель интерфейсі шын мәнінде не алғанын растаңыз.

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

Теріс жауап кэште маршруттау түзетуінен ұзақ өмір сүреді, ал ескірген жұрнақ тізімі сұраныстарды аймақ ешқашан орналаспаған жерге жіберуді жалғастырады. Тазалаңыз, қайта сұраңыз және қай сервер жауап беретінін жазып қойыңыз.

Жолдың сақталатынын екі кіші шарт шешеді: мекенжай кеңістіктері қабаттаспауы керек, ал resolver-дің қосалқы желісіндегі желілік қауіпсіздік тобы клиент пулын өткізуі керек, ол — жай ғана тағы бір көз ауқымы. Мұны VM жағынан тиімді маршрут тексеруі және клиенттен бір тікелей сұраныспен дәлелдеңіз, сонда аймақ мәселесі, жұрнақ мәселесі немесе сүзгі жетіспейтін транзитпен шатастырылмайды.

Қатысты мақалалар