Az Azure P2S DNS meghiúsul, ha a feloldó egy társított VNetben van

Pingelje a VM-et, és válaszol; kérdezze meg a nevét, és az ügyfél azt mondja, hogy a gazdagép ismeretlen. Amikor a feloldó egy társított virtuális hálózatban ül, nem pedig abban, amely a VPN-átjárót tartalmazza, ez az eredménypár várható, és a feloldó hibakeresésének semmilyen mennyisége nem változtat rajta. Ami hiányzik, az egy útválasztási szerződés, amelyet a társítás alapértelmezés szerint visszatart. Két topológia szinte azonosnak látszik papíron, és a működő és a hibás közötti különbség egy helyes irányba állított társítási kapcsolópár.

Képzeljen el egy laptopot, amely egy VNet2-beli átjáróba tunnelez, miközben a DNS-t kiszolgáló tartományvezérlő a VNet1-ben ül.

Két topológia, egy különbség

Tegye a feloldót az átjáró saját virtuális hálózatába, és a név feloldódik abban a pillanatban, amikor az alagút feláll. Egyetlen társítási beállítás sem vesz részt ebben a keresésben.

Mozgassa ugyanazt a feloldót egy társításon át, és az ügyfél továbbra is kap választ a VM-től, miközben a név ismeretlen marad. A tanúsítvány, az alagút és az ügyfél változatlan. Az egyetlen dolog, ami elmozdult, az a hely, ahol a feloldó él. A társítás útvonalat adott neki arra a címre, nem felhatalmazást az átjárónak, hogy oda forgalmat vigyen.

A oldal: engedélyezze az átjáró-átvitelt az átjáró tulajdonosánál

A társítás két virtuális hálózatot köt össze, de a kapcsolat nem tranzitív az átjárón keresztül érkező forgalom számára, és a pont-hely kérés pontosan így érkezik. Ezért a VNet2-beli átjárónak nincs jogalapja átadni a keresést a VNet1-nek, amíg a tervezés ezt meg nem engedi. Az engedély egy kapcsoló azon a társításon, amely az átjárót tartalmazó hálózat tulajdonában van.

Állítsa be az Allow gateway transit értéket a VNet2 VNet1 felé mutató társításán. A tulajdonság a társítási objektumhoz tartozik, nem az átjáró erőforráshoz, ezért a társítási panelen olvassa és módosítja. Ez az egész A oldal.

B oldal: használjon távoli átjárókat a társnál

A másik fele a tükörkép: a VNet1 VNet2 felé visszamutató társításán engedélyezze a Use remote gateways beállítást. Ugyanannak a jelzőnek mindkét végén, vagy csak az egyiken való bekapcsolása félig felépített útvonalat és változatlan eredeti tünetet hagy. Csak a VPN-átjáróval rendelkező hálózat engedélyez átvitelt, és a társ az az oldal, amely használja.

Olvassa el mindkét tulajdonságot mindkét hálózaton, ahelyett hogy az utoljára megnyitott portálpanelben bízna.

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

A pár egymás mellett látása a leggyorsabb módja egy fordított beállítás elkapásának. Az az átjáró oldalán AllowGatewayTransit false értéket jelentő társítás csomagrögzítés nélkül megmagyarázza az egész hibát.

Mit kell még megkapnia az ügyfélnek

Az útválasztás szükséges és nem elégséges, mert a pont-hely profilnak olyan DNS-címet is át kell adnia az ügyfélnek, amely válaszol, amint az átvitel működik. A platform feloldója nem ez a cím: válaszol a virtuális hálózathoz kapcsolt Azure Private DNS zónákra, de semmit a saját címtárkiszolgálóin üzemeltetett zónára, és ezt használja ez az üzembe helyezés. Irányítson rá egy ügyfelet, és a nyilvános nevek vidáman feloldódnak, miközben a belső gazdagép ismeretlen marad.

Kérdezze meg a feloldót a csatlakoztatott laptopról, mielőtt bármi mást megváltoztat.

nslookup dc01.corp.example 10.1.0.4

Az időtúllépés azt mondja, hogy az útvonal még hiányzik. A hiteles válasz visszalöki a problémát az ügyfélhez, általában egy utótaghoz, amelyet soha nem fűznek hozzá, így a rövid nevek egy nyilvános feloldóhoz utaznak, amely vidáman elbuktatja őket.

Hasonlítsa össze ugyanezt a szerződést a hely-hely oldalon

Ebből semmi nem kifejezetten a laptopoké. Cserélje az ügyfelet egy hely-hely fióktelepre, és a kétoldalú követelmény visszatér: a fióktelep közvetlenül az átjáró hálózatába érkezik, és egy két hálózattal arrébb lévő szolgáltatás még mindig a társítás mögött van.

Az átvitelt mindkét társításon engedélyezni kell, és az azt engedélyező kapcsoló a társításon él, nem az ügyfél típusán.

Mielőtt az átjárót hibáztatná

A Windows adapterenként tart feloldólistát, ezért erősítse meg, mit kapott valójában az alagút interfész, mielőtt az átjárót hibáztatja.

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

A negatív válasz túléli az útválasztás javítását a gyorsítótárban, és az elavult utótaglista továbbra is olyan helyre küldi a lekérdezéseket, ahol a zónát soha nem üzemeltették. Ürítse, kérdezze újra, és jegyezze fel, melyik kiszolgáló válaszol.

Két kisebb feltétel dönti el, hogy az útvonal tart-e: a címterek nem fedhetik át egymást, és a feloldó alhálózatán lévő hálózati biztonsági csoportnak át kell engednie az ügyfélkészletet, amely csupán egy újabb forrástartomány. Bizonyítsa ezt egy effektív útvonal-ellenőrzéssel a VM oldaláról, plusz egy közvetlen lekérdezéssel az ügyféltől, hogy egy zónaprobléma, egy utótagprobléma vagy egy szűrő soha ne legyen összetévesztve hiányzó átvitellel.