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 ирмэг дээр уншиж, өөрчилдөг. A тал бүхэлдээ энэ.

B тал: түнш дээр алсын gateway ашигла

Нөгөө хагас нь толь дүрс юм: VNet1-ээс VNet2 руу буцах peering дээр 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

Хосыг зэрэгцүүлэн харах нь урвуу тохиргоог барих хамгийн хурдан арга юм. 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 талаас үр дүнтэй маршрут шалгах, клиентээс нэг шууд асуулга илгээх замаар нотолж, бүсийн асуудал, дагаврын асуудал эсвэл шүүлтүүр дутагдаж буй транзиттай андуурч болохгүй.

Холбоотой нийтлэлүүд