Azure noktadan siteye bağlanıyor ancak hiçbir özel kaynak yanıt vermiyor

Bağlı olmak tünelin bir durumudur, erişilebilirlik hakkında bir ifade değildir. Noktadan siteye istemci IKE'yi bitirebilir, adres alabilir ve yine de hiçbir yere ulaşamaz, çünkü ağ geçidi yalnızca VNet'in zaten bildiği ağlar için trafiği iletir. Bu beş kontrolü sırayla yapın ve ilk başarısızlıkta durun. İleri atlamak, bir DNS sorununun bir saat boyunca güvenlik duvarı sorunu olarak ele alınmasının yoludur.

Sıra, listeden daha önemlidir.

Kontrol 1: tünelin neyi taşıması gerektiğine karar verin

Azure VPN Gateway tüneli sonlandırır ve VNet'e ait trafiği iletir; ogenel bir internet çıkışı değildir. Kullanıcılar gezinmelerinin Azure üzerinden çıkmasını bekliyorsa, herhangi bir istemci ayarı devreye girmeden önce tasarım yanlıştır. Yerel internetin yerel yolda kalması için split tunneling'i açın ve gerçekten sabit bir çıkış adresi gerektiğinde NAT örneği veya siteden siteye tünel kullanın.

Herhangi bir şeyi test etmeden önce istemcinin nereye ulaşması gerektiğini yazın. Bu liste olmadan her kısmi sonuç ilerleme gibi görünür.

Kontrol 2: sertifikalardan önce adres alanlarını karşılaştırın

Örtüşme daha geniş aralıklara göre değerlendirilir, bu yüzden alt ağ düzeyinde farklı görünen iki ağ, ana blokları örtüşüyorsa yine çakışır. Ağ geçidi alt ağı ayrılmış ve SKU için yeterince büyük olmalı ve istemci adres havuzu VNet ile ya da bir peering üzerinden erişilebilen herhangi bir şeyle çakışmamalıdır. Planı değiştirin ve yeniden dağıtın, çünkü telafi için rota eklemek bazı hedefler için çalışan, diğerleri için ise açıklanamaz biçimde çalışmayan bir tünel üretir. Sağlama burada yüksek sesle başarısız olur ve bu iyi durumdur.

Kimlik doğrulama bir sonraki kapıdır. Sertifika, RADIUS ve Entra ID profilleri birbirinin yerine geçmez ve istemci paketi her biri için farklıdır.

Kontrol 3: özel bir adı içeriden çözümleyin

İstemci, indirilen profil VNet'in DNS sunucularını taşımıyorsa kendi çözümleyicisini korur ve bu liste indirme anında gömülür. VNet içine bir forwarder ekleyin, onu VNet'in DNS sunucusu olarak ayarlayın, sonra istemci paketini yeniden indirip içe aktarın. Eski paketi yeniden kullanmak yalnızca eski çözümleyici listesini test eder.

Önce bir adresi test edin, çünkü bu yönlendirmeyi adlandırmadan tek adımda ayırır: Test-NetConnection 10.20.1.4 -Port 3389.

Adres yanıt verip ad vermiyorsa, çözümleyiciye doğrudan Resolve-DnsName files.corp.example -Server 10.20.0.4 ile sorun. İkisi de başarısız olursa hata DNS'te değildir ve DNS ayarlarını düzenlemeyi bırakmalısınız. 168.63.129.16 adresindeki Azure platform DNS'i yalnızca VNet içinden yanıt verir, bu yüzden dışarıdaki bir istemci o adresi çözümleyici olarak kullanamaz.

Kontrol 4: tünelin arkasındaki hizmeti test edin

Sağlıklı bir tünel ile kapalı bir port istemci tarafından aynı görünür. Misafir güvenlik duvarını, ardından alt ağdaki veya NIC'teki ağ güvenliği grubunu, ardından hizmetin yalnızca loopback'te değil özel adreste dinleyip dinlemediğini kontrol edin. İnternete kural açmak yerine istemci havuzuna kaynak olarak izin verin ve Azure Files'a SMB'nin özel uç nokta yolunun tünelden geçmesi gerektiğini unutmayın. Bir kaynak IP ile yanıt verip adla vermiyorsa, ağ geçidine dokunmak yerine kontrol 3'e dönün.

Çalışırken katmanları bir tablo ayrı tutar:

Kontrol 5: yükseltmeden önce profili kaydedin

Bilete ağ geçidi türünü, tünel türünü, kimlik doğrulama yöntemini ve istemci işletim sistemini yazın. Sertifikalı IKEv2 profili ile RADIUS profili farklı nedenlerle başarısız olur ve başka bir tünel türü için oluşturulmuş bir istemci yalnızca ağ geçidi uyumlu bir protokol sunduğunda bağlanır.

Küçük bir ekip için kalıcı tasarım bir VNet, bir DNS forwarder ve belgelenmiş bir split-tunnel istemcisidir. Gereksinim sabit bir genel çıkışsa, kontrol ettiğiniz bir güvenlik duvarında siteden siteye tüneli sonlandırın ve internet trafiğini oraya yönlendirin, noktadan siteye ağ geçidinden hiç yapılmadığı bir işi istemek yerine.