Azure P2S DNS не успева кога resolver е во поврзана VNet

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

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

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

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

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

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

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

Peering-от поврзува две виртуелни мрежи, но врската не е преодна за сообраќај што пристигнува преку gateway, а барањето од точка до локација пристигнува токму така. Затоа gateway-от во VNet2 нема основа да го предаде пребарувањето на VNet1 додека дизајнот тоа не го дозволи. Дозволата е прекинувач на peering-от што го поседува мрежата со gateway-от.

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

Страна B: користете далечински gateway-и кај партнерот

Другата половина е огледална слика: на peering-от од VNet1 назад кон VNet2 вклучете Use remote gateways. Вклучувањето на истото знаменце на двата краја, или само на едниот, остава половично изградена патека и првичниот симптом непроменет. Само мрежата со gateway-от 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

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

Што клиентот сè уште мора да добие

Рутирањето е неопходно, но не и доволно, бидејќи профилот од точка до локација мора да му даде на клиентот и DNS-адреса што одговара кога транзитот работи. Resolver-от на платформата не е таа адреса: одговара на Azure Private DNS зони поврзани со виртуелната мрежа, но ништо за зона што е хостирана на вашите сопствени сервери за директориум, а тоа е она што го користи ова распоредување. Насочете клиент кон него и јавните имиња весело се решаваат, додека внатрешниот домаќин останува непознат.

Прашајте го resolver-от од поврзаниот преносен компјутер пред да промените нешто друго.

nslookup dc01.corp.example 10.1.0.4

Истекот на време вели дека патеката сè уште недостасува. Авторитативниот одговор го враќа проблемот кај клиентот, обично наставка што никогаш не се додава, па кратките имиња патуваат до јавен resolver што весело ги провалува.

Споредете го истиот договор на страната од локација до локација

Ништо од ова не и припаѓа посебно на преносните компјутери. Заменете го клиентот со огранок од локација до локација и двосмисленото барање се враќа: огранокот пристигнува директно во мрежата на gateway-от, а услугата две мрежи подалеку сè уште е зад peering-от.

Транзитот мора да се додели на двата peering-а, а прекинувачот што го доделува живее на peering-от, а не на типот на клиент.

Пред да го обвините gateway-от

Windows држи список на resolver-и за секој адаптер, затоа потврдете што навистина добил тунелскиот интерфејс пред да го обвините gateway-от.

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

Негативниот одговор го надживува поправката на рутирањето во кешот, а застарениот список на наставки продолжува да праќа барања некаде каде што зоната никогаш не била хостирана. Исчистете, прашајте повторно и забележете кој сервер одговара.

Два помали услови одлучуваат дали патеката ќе се задржи: адресните простори не смеат да се преклопуваат, а мрежната безбедносна група во подмрежата на resolver-от мора да го пропушти клиентскиот пул, што е само уште еден изворен опсег. Докажете го тоа со проверка на ефективни рути од страната на VM-от плус едно директно барање од клиентот, за да не се помешаат проблем со зона, проблем со наставка или филтер со недостигачки транзит.

Поврзани статии