DNS у Azure P2S не працуе, калі рэзалвер знаходзіцца ў злучанай VNet

Кліент можа дасягаць сваёй віртуальнай сеткі і ўсё роўна не развязаць імёны ў злучанай сетцы. Пірынг — не транзіт шлюза, пакуль абодва бакі гэтага не дазволяць.

Пінгуйце ВМ — яна адказвае; спытайце яе імя — кліент кажа, што хост невядомы. Калі рэзалвер знаходзіцца ў злучанай віртуальнай сетцы, а не ў той, дзе размяшчаецца шлюз VPN, гэтая пара вынікаў чаканая, і ніякая дыягностыка рэзалвера гэтага не зменіць. Бракуе дагавора маршрутызацыі, які пірынг стрымлівае па змаўчанні. Дзве тапалогіі выглядаюць амаль аднолькава на паперы, а розніца паміж працаздольнай і зламанай — гэта пара перамыкачоў пірынгу, усталяваных у правільным кірунку.

Уявіце ноўтбук, які тунелюе да шлюза ў VNet2, а кантролер дамена, які абслугоўвае DNS, сядзіць у VNet1.

Дзве тапалогіі, адна розніца

Змесціце рэзалвер унутры ўласнай віртуальнай сеткі шлюза — і імя развяжацца ў момант узняцця тунеля. Ніякая налада пірынгу ў гэтым пошуку не ўдзельнічае.

Перанясіце той жа рэзалвер праз пірынг — і кліент па-ранейшаму атрымлівае адказ ад ВМ, а імя застаецца невядомым. Сертыфікат, тунель і кліент не змяніліся. Адзінае, што перамясцілася, — гэта месца, дзе жыве рэзалвер. Пірынг даў яму маршрут да гэтага адраса, а не права шлюзу несці туды трафік.

Бок 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

Адмоўны адказ перажывае выпраўленне маршрутызацыі ў кэшы, а састарэлы спіс суфіксаў працягвае адпраўляць запыты туды, дзе зоны ніколі не было. Ачысціце кэш, запытайце зноў і адзначце, які сервер адказвае.

Дзве драбнейшыя ўмовы вырашаюць, ці ўтрымаецца шлях: адрасныя прасторы не павінны перакрывацца, а група сеткавай бяспекі ў падсетцы рэзалвера павінна пускаць пул кліентаў, гэта проста яшчэ адзін дыяпазон крыніц. Дакажыце гэта праверкай эфектыўных маршрутаў з боку ВМ плюс адзін прамы запыт ад кліента, каб праблема зоны, праблема суфікса ці фільтр ніколі не былі прынятыя за адсутны транзіт.

Падобныя артыкулы