Azure P2S DNS uğursuz olur: həlledici peer VNet-də yerləşir

VM-ə ping göndərin, cavab verir; adını soruşun, müştəri hostun naməlum olduğunu deyir. Həlledici VPN gateway-ni saxlayan şəbəkədə deyil, peer virtual şəbəkədə yerləşdikdə bu iki nəticə gözləniləndir və həlledici ilə bağlı heç bir diaqnostika bunu dəyişmir. Çatışmayan şey peerinqin standart olaraq saxladığı marşrut müqaviləsidir. İki topologiya kağız üzərində demək olar ki, eyni görünür və işləyənlə pozulmuş arasındakı fərq düzgün istiqamətdə qurulmuş bir cüt peerinq açarıdır.

Təsəvvür edin: noutbuk VNet2-dəki gateway-ə tunel açır, DNS xidməti göstərən domen nəzarətçisi isə VNet1-də oturur.

İki topologiya, bir fərq

Həlledicini gateway-in öz virtual şəbəkəsinə qoyun, tunel qalxan kimi ad həll olunur. Heç bir peerinq parametri bu axtarışda iştirak etmir.

Eyni həlledicini peerinqin o tərəfinə keçirin, müştəri VM-dən yenə cavab alır, ad isə naməlum qalır. Sertifikat, tunel və müştəri dəyişməyib. Yeganə dəyişən həlledicinin harada yerləşməsidir. Peerinq ona həmin ünvana marşrut verdi, gateway-ə oraya trafik daşımaq səlahiyyəti deyil.

A tərəfi: gateway sahibində gateway tranzitinə icazə verin

Peerinq iki virtual şəbəkəni birləşdirir, lakin bu birləşmə gateway-dən gələn trafik üçün keçidli deyil və point-to-site sorğusu məhz belə gəlir. Buna görə VNet2-dəki gateway, dizayn icazə verməyincə axtarışı VNet1-ə ötürmək hüququna malik deyil. İcazə gateway-i saxlayan şəbəkəyə məxsus peerinqdəki açardır.

VNet2-nin VNet1-ə doğru peerinqində Allow gateway transit seçimini qoyun. Bu xassə gateway resursuna deyil, peerinq obyektinə aiddir, ona görə onu peerinq bıçağında oxuyub dəyişirsiniz. A tərəfinin hamısı budur.

B tərəfi: peer tərəfdə uzaq gateway-lərdən istifadə edin

Digər yarısı güzgü əksidir: VNet1-in VNet2-yə geri peerinqində Use remote gateways seçimini aktivləşdirin. Eyni bayrağı hər iki uçda və ya yalnız bir uçda qoşmaq yarımçıq yol və ilkin simptom buraxır. Yalnız VPN gateway-i olan şəbəkə tranzitə icazə verir, peer isə ondan istifadə edən tərəfdir.

Son açdığınız portal bıçağına güvənmək əvəzinə hər iki şəbəkədə hər iki xassəni oxuyun.

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

Cütü yan-yana görmək tərs qurulmuş parametri tutmağın ən sürətli yoludur. Gateway tərəfində AllowGatewayTransit false göstərən peerinq bütün nasazlığı paket tutmadan izah edir.

Müştəri hələ nə almalıdır

Marşrutlaşdırma zəruridir, amma kifayət deyil, çünki point-to-site profili müştəriyə tranzit işləyəndən sonra cavab verən DNS ünvanı da verməlidir. Platforma həlledicisi o ünvan deyil: o, virtual şəbəkəyə bağlanmış Azure Private DNS zonalarına cavab verir, amma öz kataloq serverlərinizdə yerləşən zonaya heç nə demir, bu quraşdırma məhz ondan istifadə edir. Müştərini ora yönəltsəniz, ictimai adlar rahat həll olunur, daxili host isə naməlum qalır.

Başqa heç nəyi dəyişməzdən əvvəl qoşulmuş noutbukdan həllediciyə sorğu göndərin.

nslookup dc01.corp.example 10.1.0.4

Vaxt aşımı yolun hələ çatışmadığını bildirir. Səlahiyyətli cavab problemi müştəriyə qaytarır, adətən heç vaxt əlavə olunmayan suffiks, ona görə qısa adlar onları rahat uğursuz edən ictimai həllediciyə gedir.

Eyni müqaviləni site-to-site tərəfində müqayisə edin

Bunların heç biri xüsusilə noutbuklara aid deyil. Müştərini site-to-site filialı ilə dəyişin və ikitərəfli tələb qayıdır: filial gateway şəbəkəsinə birbaşa gəlir, iki şəbəkə aralıdakı xidmət isə hələ peerinqin arxasındadır.

Tranzit hər iki peerinqdə verilməlidir və onu verən açar müştəri tipində deyil, peerinqdə yerləşir.

Gateway-i günahlandırmazdan əvvəl

Windows hər adapter üçün həlledici siyahısı saxlayır, ona görə gateway-i günahlandırmazdan əvvəl tunel interfeysinin həqiqətən nə aldığını təsdiqləyin.

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

Mənfi cavab keşdə marşrut düzəlişindən uzun yaşayır və köhnəlmiş suffiks siyahısı sorğuları heç vaxt zonanı saxlamayan yerə göndərməyə davam edir. Keşi təmizləyin, yenidən soruşun və hansı serverin cavab verdiyini qeyd edin.

Yolun davam edib-etmədiyini iki kiçik şərt həll edir: ünvan məkanları üst-üstə düşməməlidir, və həlledicinin subnetindəki şəbəkə təhlükəsizlik qrupu müştəri hovuzunu qəbul etməlidir, bu sadəcə başqa mənbə aralığıdır. Bunu VM tərəfdən effektiv marşrut yoxlaması və müştəridən birbaşa bir sorğu ilə sübut edin ki, zona problemi, suffiks problemi və ya filtr heç vaxt çatışmayan tranzit ilə qarışdırılmasın.