Azure P2S DNS не успева када је resolver у повезаној VNet

Клијент може да стигне до своје виртуелне мреже и ипак не реши имена у повезаној мрежи. Peering није транзит gateway-а док обе стране то не кажу.

Пошаљите ping на VM и она одговара; питајте за њено име и клијент каже да је host непознат. Када resolver стоји у повезаној виртуелној мрежи, а не у оној која држи VPN gateway, тај пар резултата је очекиван и никакво отклањање проблема са resolver-ом то не мења. Недостаје уговор о рутирању који peering подразумевано задржава. Две топологије изгледају готово идентично на папиру, а разлика између радне и покварене је пар peering прекидача постављених у правом смеру.

Замислите преносни рачунар који тунелира у gateway у VNet2, док контролер домена који служи DNS седи у VNet1.

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

Ставите resolver унутар gateway-ове сопствене виртуелне мреже и име се реши чим се тунел подигне. Ниједна peering поставка не учествује у том претраживању.

Преместите исти resolver преко peering-а и клијент и даље добија одговор од VM-а док име остаје непознато. Сертификат, тунел и клијент су непромењени. Једино што се померило јесте где resolver живи. Peering му је дао руту до те адресе, не овлашћење gateway-у да тамо носи саобраћај.

Страна A: дозволите транзит gateway-а код власника gateway-а

Peering спаја две виртуелне мреже, али спој није транзитиван за саобраћај који долази кроз gateway, а захтев point-to-site долази управо тако. Gateway у VNet2 зато нема основа да преда претраживање у VNet1 док му дизајн то не дозволи. Дозвола је прекидач на peering-у који поседује мрежа са gateway-ом.

Поставите Allow gateway transit на peering-у VNet2 према VNet1. Својство припада peering објекту, не ресурсу gateway-а, па га читате и мењате на peering оштрици. То је цела страна A.

Страна B: користите удаљене gateway-е на партнеру

Друга половина је огледалска слика: на peering-у VNet1 назад ка VNet2 укључите Use remote gateways. Укључивање исте заставице на оба краја, или само на једном, оставља пола изграђену путању и изворни симптом нетакнутим. Само мрежа са VPN gateway-ом дозвољава транзит, а партнер је страна која га користи.

Читајте оба својства на обе мреже уместо да верујете оштрици портала коју сте последњу отворили.

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

Видети пар један уз други најбржи је начин да ухватите обрнуту поставку. Peering који на страни gateway-а пријављује AllowGatewayTransit false објашњава цео квар без хватања пакета.

Шта клијент још мора да добије

Рутирање је нужно, али не и довољно, јер профил point-to-site мора клијенту да преда и DNS адресу која одговара када транзит проради. Resolver платформе није та адреса: одговара на Azure Private DNS зоне повезане са виртуелном мрежом, али ништа за зону хостовану на вашим сопственим директоријумским серверима, а то је оно што користи ово распоређивање. Усмерите клијента на њега и јавна имена се весело решавају док унутрашњи host остаје непознат.

Питајте 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 стране плус једним директним упитом са клијента, да се проблем зоне, проблем суфикса или филтер никада не побркају са недостајућим транзитом.

Повезани чланци