Azure P2S DNS, çözümleyici eşlenmiş bir VNet'te olduğunda başarısız olur

İstemci kendi sanal ağına ulaşabilir ve yine de eşlenmiş bir ağdaki adları çözemez. Peering, iki taraf da kabul edene kadar gateway geçişi değildir.

VM'e ping atın, yanıt verir; adını sorun, istemci ana makinenin bilinmediğini söyler. Çözümleyici VPN gateway'ini barındıran ağda değil de eşlenmiş bir sanal ağda oturduğunda, bu iki sonuç beklenen sonuçtur ve çözümleyici sorun gidermenin hiçbir miktarı bunu değiştirmez. Eksik olan, peering'in varsayılan olarak alıkoyduğu yönlendirme sözleşmesidir. İki topoloji kâğıt üzerinde neredeyse aynı görünür ve çalışanla bozuk arasındaki fark doğru yöne ayarlanmış bir çift peering anahtarıdır.

Bir dizüstü bilgisayarın VNet2'deki bir gateway'e tünel açtığını, DNS hizmeti veren etki alanı denetleyicisinin ise VNet1'de oturduğunu düşünün.

İki topoloji, bir fark

Çözümleyiciyi gateway'in kendi sanal ağına koyun, tünel kalktığı anda ad çözülür. Hiçbir peering ayarı o aramaya katılmaz.

Aynı çözümleyiciyi bir peering'in öbür tarafına taşıyın, istemci yine VM'den yanıt alır ama ad bilinmez kalır. Sertifika, tünel ve istemci değişmemiştir. Yer değiştiren tek şey çözümleyicinin nerede yaşadığıdır. Peering ona o adrese bir yol verdi, gateway'e oraya trafik taşıma yetkisi değil.

A tarafı: gateway sahibinde gateway geçişine izin verin

Peering iki sanal ağı birleştirir, ancak bu birleşim gateway üzerinden gelen trafik için geçişli değildir ve noktadan siteye istek tam olarak böyle gelir. Bu nedenle VNet2'deki gateway, tasarım izin verene kadar aramayı VNet1'e devretme yetkisine sahip değildir. İzin, gateway'i barındıran ağın sahip olduğu peering üzerindeki bir anahtardır.

VNet2'den VNet1'e doğru peering üzerinde Allow gateway transit ayarını yapın. Bu özellik gateway kaynağına değil peering nesnesine aittir, bu yüzden onu peering blade'inde okuyup değiştirirsiniz. A tarafının tamamı budur.

B tarafı: eşte uzak gateway'leri kullanın

Diğer yarısı ayna görüntüsüdür: VNet1'den VNet2'ye geri giden peering üzerinde Use remote gateways seçeneğini etkinleştirin. Aynı bayrağı iki uçta ya da yalnızca bir uçta açmak, yarı yapılmış bir yol ve özgün belirtiyle baş başa bırakır. Yalnızca VPN gateway'i olan ağ geçişe izin verir ve eş, onu kullanan taraftır.

En son açtığınız portal blade'ine güvenmek yerine her iki ağda her iki özelliği okuyun.

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

Çifti yan yana görmek, ters ayarlanmış bir değeri yakalamanın en hızlı yoludur. Gateway tarafında AllowGatewayTransit false bildiren bir peering, tüm arızayı paket yakalamadan açıklar.

İstemcinin hâlâ alması gerekenler

Yönlendirme gereklidir ve yeterli değildir, çünkü noktadan siteye profili istemciye geçiş çalıştıktan sonra yanıt veren bir DNS adresi de vermelidir. Platform çözümleyicisi o adres değildir: sanal ağa bağlı Azure Private DNS bölgelerini yanıtlar, ancak kendi dizin sunucularınızda barındırılan bir bölge için hiçbir şey yanıtlamaz ve bu dağıtım tam olarak onu kullanır. Bir istemciyi ona yönlendirin, genel adlar neşeyle çözülürken iç ana makine bilinmez kalır.

Başka bir şeyi değiştirmeden önce bağlı dizüstü bilgisayardan çözümleyiciye sorun.

nslookup dc01.corp.example 10.1.0.4

Bir zaman aşımı, yolun hâlâ eksik olduğunu söyler. Yetkili bir yanıt sorunu istemciye geri iter, genellikle hiç eklenmeyen bir son ek, bu yüzden kısa adlar onları neşeyle başarısız kılan genel bir çözümleyiciye gider.

Aynı sözleşmeyi siteden siteye tarafında karşılaştırın

Bunların hiçbiri özellikle dizüstü bilgisayarlara ait değildir. İstemciyi siteden siteye bir şube ile değiştirin, iki taraflı gereksinim geri döner: şube doğrudan gateway ağına gelir ve iki ağ ötedeki hizmet hâlâ peering'in arkasındadır.

Geçiş her iki peering'de verilmelidir ve onu veren anahtar istemci türünde değil peering'de yaşar.

Gateway'i suçlamadan önce

Windows her bağdaştırıcı için bir çözümleyici listesi tutar, bu yüzden gateway'i suçlamadan önce tünel arabiriminin gerçekte ne aldığını doğrulayın.

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

Olumsuz bir yanıt önbellekte yönlendirme düzeltmesinden daha uzun yaşar ve eski bir son ek listesi sorguları hiç barındırılmamış bir yere göndermeye devam eder. Temizleyin, yeniden sorun ve hangi sunucunun yanıtladığını not edin.

Yolun dayanıp dayanmayacağını iki küçük koşul belirler: adres alanları çakışmamalıdır, ve çözümleyicinin alt ağındaki ağ güvenlik grubu istemci havuzunu geçirmelidir; bu yalnızca başka bir kaynak aralığıdır. Bunu VM tarafından etkin yol denetimi ve istemciden bir doğrudan sorgu ile kanıtlayın, böylece bir bölge sorunu, bir son ek sorunu veya bir filtre asla eksik geçişle karıştırılmaz.

İlgili makaleler