Azure P2S VPN dönüş trafiği yalnızca tek yönde çalışıyor

Tünel simgesi yeşil, NSG izin veriyor gibi görünüyor, etkin yollar doğru görünüyor ve yine de VM bağlı istemciye geri dönüş bağlantısı açamıyor. Genel varsayım, çalışan bir point-to-site tünelinin simetrik olduğudur: istemci VM'ye ulaşabiliyorsa VM de istemciye ulaşır. Bu varsayım, yapılandırmadaki değil akıl yürütmedeki hatadır. Bir tünel, istenmeyen bir akışın bir yönünü taşıyıp diğerini düşürebilir ve düzeltme, onu hangi katmanın düşürdüğüne bağlıdır.

Mit: bağlı bir tünel iki yönlü tüneldir

VPN tüneli bir kablo değil, ilke yoludur. Her yön seçiciler, yollar ve filtrelerle eşleştirilir ve bunlardan herhangi biri bir yöne izin verirken diğerini engelleyebilir.

Pratikte asimetri o kadar yaygındır ki yön, son değil ilk testte yer almalıdır. İstemci başlatır, ağ geçidi akışı izler ve yanıt oluşturulan durumu takip eder. Yeni bir akış başlatan VM'de böyle bir durum yoktur, bu nedenle dönüş yolunun açıkça yönlendirilebilir ve izinli olmasına bağlıdır. Bu yol yoksa bağlantı denemesi herhangi bir uygulama görmeden ölür.

Erişilebilirliği test etmeden önce yönü test edin

Bir istemci adresi, bir VM adresi ve bir protokol seçin. İstemciden bağlanın ve sonucu kaydedin; ardından aynı testi VM'den başlatın ve onu da kaydedin. Birincisi başarılı olup ikincisi başarısız olursa istemci havuzu, ağ geçidi ilişkilendirmesi ve istemciden VNet'e giden yol çalışıyor demektir.

Sonraki adım kanıttır, daha fazla kural değil. VM alt ağındaki NSG'yi iki yönde kontrol edin, VM'nin NIC'indeki etkin yolları okuyun ve istemci trafik gönderirken VM'de paket yakalayın. Yanıtsız gelen bir istek filtre veya dönüş yolu sorunudur; hiç gelmeyen bir istek yol sorunudur. Başarısız bir ping'i VM'e ulaşılamadığının kanıtı saymayın, çünkü ICMP ilkesi TCP çalışırken yanıtı düşürebilir.

IKEv2 point-to-site dönüş yolu olağan şüphelidir

Bu makalenin arkasındaki Azure raporunda istemci IKEv2 üzerinden VM'lere ulaşabiliyordu, ancak VM'den istemciye gelen ICMP, ağ geçidinin tünel türü OpenVPN olarak değiştirilene kadar başarısız oldu. Raporu yazan kişi, Microsoft'un IKEv2 point-to-site yolunda bir sınırlamayı doğruladığını belirtiyor: istemci oturumu başlatmadıkça VM'den istemciye dönüş trafiği simetrik olarak yönlendirilmiyor. IKEv2 trafik seçicilerine dayanır ve ağ geçidi o durumda dönüş yönüne uymadı.

Bu, OpenVPN'i genel olarak daha iyi tünel türü yapmaz. Bu, tünel türünü bu iş yükü için test matrisinde bir değişken yapar.

Tünel türünü değiştirmek bir hizmet değişikliğidir, anahtar değil. Her istemcinin uyumlu bir profile ihtiyacı vardır ve ağ geçidi farklı bir sertifika veya kimlik doğrulama kurulumu gerektirebilir. Tek yönlü davranışı bir test istemcisi ve bir test VM'i ile yeniden üretin, türü onaylanmış bir programa göre değiştirin ve ardından aynı yön testlerini tekrarlayın. Davranış değişiklikten sonra da sürüyorsa tünel türü neden değildi ve üretime dokunmadan sorunu daralttınız.

Mit: broadcast keşfi VNet kenarını aşar

İkinci varsayım ilgisiz bir nedenle çöker. Azure sanal ağı broadcast trafiği taşımaz, bu nedenle bir VM site-to-site veya point-to-site bağlantısı üzerinden yerel ağdan broadcast çerçeveleri alamaz. Eşlerini broadcast ile bulan uygulamalar, örneğin eski dosya taraması veya bazı cihaz keşif protokolleri, yollar nasıl yazılırsa yazılsın uzak tarafı asla görmez.

Broadcast keşfini DNS adları, bir dizin hizmeti veya açık bir eş listesiyle değiştirin. Uygulamanın unicast alternatifi yoksa tasarımın daha geniş bir tünele değil, farklı bir keşif mekanizmasına ihtiyacı vardır.

Neyi değiştirmeli ve nasıl kanıtlamalı

Yön testi yalnızca IKEv2'de başarısız olursa ağ geçidinin tünel türünü, istemci adres havuzunu ve tam ICMP veya TCP testini kaydedin, ardından etkilenen istemciler için onaylanmış bir OpenVPN profili değerlendirin. Her tünel türünde başarısız olursa dönüş yolu üzerinde çalışın: istemci adresi VM alt ağından yönlendirilebilir olmalı, kullanıcı tanımlı her yol geçerli bir sonraki atlama noktasını göstermeli ve istemcinin güvenlik duvarı gelen akışı kabul etmelidir. NSG ve yol kanıtlarını bilete ekleyin.

Ping ile değil, uygulama ile doğrulayın. Bir değişiklikten sonra başarılı bir ICMP alışverişi hizmet bağlantı noktası, kimlik doğrulaması veya ad çözümlemesi hakkında hiçbir şey söylemez. Yeniden bağlandıktan sonra testi yineleyin, çünkü havuzdan farklı bir adres alan istemci sonucu değiştirebilir. Ardından istemci uyuyup uyandıktan sonra bir kez daha yineleyin, çünkü tek yönlü davranış genellikle devam ettirilen bir oturumda yeniden ortaya çıkar.