Azure'da VPN cihazı çalıştıran VM neden dönüş yolunu kaybeder
Azure VM'deki bir VPN cihazı için UDR, ağ kartının yönlendirme bayrağı ve konuk ilkesinin uyuşması gerekir. Tek bir şube isteğini üçünün içinden izleyin.
VPN cihazı çalıştıran bir Azure VM, birbirinden bağımsız iki karar sisteminin içindedir. Bir paketin alt ağdan nereden çıkacağına Azure, yol tabloları ve ağ kartının yönlendirme ayarıyla karar verir. Şifresi çözülen paketin ileri aktarılıp aktarılmayacağına cihazın kendi işletim sistemi karar verir. Kusursuz şekilde kurulan bir tünel yine de ikinci sistemde başarısız olabilir ve bu tür dağıtımların çoğu tam orada durur.
Tek yolun üç sahibi
Şu şubeden bir ağ alın: 192.168.50.0/24 ve şu aralıkta bir iş yükü alt ağı alın: 10.0.10.0/24, cihaz ise şu adreste olsun: 10.0.0.4 kendi alt ağında. Tek bir istek üç ayrı yapılandırmaya dokunur.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Çoğu kuruluşta her satırın sahibi farklı bir ekiptir, bu yüzden bu arıza genellikle bir değil üç bilet olarak gelir.
Cihazı işaret eden yol
İş yükü alt ağına bir yol tablosu ilişkilendirin ve şube ön ekinin sonraki atlamasını Virtual appliance türünde şu adresle tanımlayın: 10.0.0.4 olarak adresi kullanın. Cihazın erişilebilir özel adresini kullanın, asla onun genel VPN giriş noktasını. Sonraki atlama, iş yükü alt ağının hâlihazırda ulaşabildiği bir adres olmalıdır. Varsayılan yolu bilinçli olarak değiştirmeye karar vermediyseniz iş yükünün geri kalan yönlendirmesine dokunmayın.
Cihazı kendi alt ağında tutun ve şube trafiğini cihaza gönderen yolun cihazın kendi giden yolunu da yakalamadığından emin olun. Böyle bir döngü, yanıtı olmayan sağlıklı bir tünele benzer ve bunu gece saat 2'de ayıklamak son derece can sıkıcıdır.
Herkesin unuttuğu ağ kartı bayrağı
Azure'da ağ kartı başına bir IP yönlendirme ayarı vardır ve varsayılan olarak kapalıdır. Bu ayar, yönlendiren kartın kendisine değil başka bir şeye adreslenmiş paketleri alması nedeniyle vardır ve bunları sessizce düşürmek diğer herkes için güvenli varsayılandır.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true tek bir arabirim için bunu açar. Microsoft'un ağ kartında yönlendirme rehberi trafiği yönlendiren her bağlı kartta bu ayarı gerektirir, bu yüzden tek kartlı bir cihaz bile onu o kartta ayarlamak zorundadır.
Bayrak bir yol değildir ve bir güvenlik duvarı kuralı da değildir. Açmak yalnızca izin verir, başka bir şey yapmaz.
Konuk şifresi çözülen paketle ne yapar
Tünel bittiğinde cihazın kendi yığını bir sonraki kararı verir. Linux konuğunda IPv4 yönlendirme bir çalışma zamanı ayarıdır ve sysctl -w net.ipv4.ip_forward=1 bir sonraki açılışa kadar sürer. Bunun yerine onu şu dizin altındaki bir dosyaya kalıcı olarak yazın: /etc/sysctl.d/ . Satıcı cihazının kendi eşdeğeri vardır ve satıcı platformuna yapıştırılan Linux talimatları genellikle hiçbir şey yapmaz.
Konuğun güvenlik duvarı ilkesi yine ayrıdır, iş yükünün ağ güvenlik grubu da öyle. VM'nin genel adresine UDP 500 ve 4500 izni vermek tüneli korur; şifresi çözülen bir şube isteğinin iş yükü bağlantı noktasına ulaşıp ulaşamayacağı hakkında hiçbir şey söylemez.
Bir isteği ve yanıtını izleyin
İzin verilen tek bir akış seçin ve baştan sona izleyin. Şube için şu adrese bir yol gerekir: 10.0.10.0/24 site bağlantısı üzerinden; cihazın iş yükü alt ağına bir teslim yolu olmalı; iş yükü alt ağının da şubeye doğru bir dönüş yolu olmalı.
Tasarımın şubenin kaynak adresini koruyup korumayacağına yoksa çevirip çevirmeyeceğine erken karar verin. NAT iş yükünün gördüğünü değiştirir, bu yüzden erişim kuralları tahmin edilen bir ağ geçidi adresini değil gerçekten seçtiğiniz modeli tanımlamalıdır.
Başarılı bir el sıkışma o zincirin yalnızca bir halkasını kanıtlar. Yanıt aynı cihazdan geri döndüğünde ve iş yükünün kendi ilkesi buna izin verdiğinde yol tamamlanır.