Tek bir Azure VPN VM üzerinde iki genel IP: hangisi ne yapar

Tek bir Azure VPN VM üzerinde iki genel IP, nadiren gerçekleşen bir beklenti yaratır: istemcilerin bağlandığı adres, web sitelerinin gördüğü adres de olacaktır. Bu sonucu üç bağımsız karar üretir ve yalnızca ilki tünel dinleyicisiyle ilgilidir. İkincisi, iletilen istemci trafiği için kullanılan konuk kaynağıdır; üçüncüsü ise o kaynağa uygulanan Azure çıkış yöntemidir. Birini değiştirin, diğer ikisi oldukları yerde kalır, bu yüzden her birini açıkça kararlaştırın.

Karar 1: tünel nerede biter

Bir Azure genel IP'si NIC üzerindeki özel bir IP yapılandırmasıyla ilişkilidir; konuk işletim sistemi içinde eklediğiniz bir adres değildir. Eşlemeyi varsaymak yerine okuyun: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. O sorgu hangi özel adresi döndürürse döndürsün, konuğun gerçekten sahip olması gereken adres odur.

Bir NIC birden çok IP yapılandırması taşıyabilir, bu nedenle iki genel adres iki NIC gerektirmez. Tasarım gerçekten iki NIC kullanıyorsa, her biri kendi konuk rotalarını ve sonraki atlamalarını getirir ve siz basitleştirmek yerine bir yönlendirme kararı eklemiş olursunuz.

Açık yerel bağlaması olan bir hizmet için konuğun gerçek özel adresine bağlanın, asla genel yer tutucuya değil. Tüm adresleri kabul eden bir dinleyici, kendisine ulaşan her IP yapılandırması üzerinden trafik alır, bu yüzden girişi bağlama sırasının belirlemesini ummak yerine ağ güvenlik grubu ve ana makine güvenlik duvarıyla sınırlayın.

Karar 2: iletilen istemci hangi kaynağı kullanır

Ağ geçidi bir istemci isteğinin şifresini çözdükten sonra ilettiği paket, VPN dinleyicisine ulaşan paketten farklıdır. Konuğun iletme etkin, akışa izin veren bir güvenlik duvarı ilkesi ve bulut tasarımının izin verdiği bir kaynak adresi olmalıdır. İstemcinin iç adresini çevirirseniz, Azure tam olarak o çevrilmiş kaynağı değerlendirir, istemcinin iç adresini değil.

Dar bir SNAT kuralı konuk özel kaynağını seçebilir, ancak alt akıştaki bir Azure çevirisini geçersiz kılamaz. VM içinde istemci başına hesap verebilirlik gerekiyorsa SNAT seçin; alt ağın çıkış tasarımı zaten kararlı bir genel kaynak sağlıyorsa ve ikinci çeviri yalnızca durum ekleyecekse bundan vazgeçin.

Karar 3: hangi Azure çıkış yöntemi kazanır

Microsoftçıkış öncelik sırasınıbelgeler: bir cihaza veya ağ geçidine uygulanabilir rota önceliklidir ve ilgili yolda alt ağ NAT Gateway bağlantısı, örnek düzeyindeki genel IP'ye göre önceliklidir. Bu sıra, 10.20.0.5'e çevirinin bir web sitesinin 198.51.100.20'yi göreceğini kanıtlamamasının nedenidir. Çıkış tasarımını kabul etmeden önce geçerli rota tablosunu, NAT Gateway ilişkilendirmesini ve NIC'nin genel IP'sini birlikte okuyun.

Şunu ayrı tutun:Azure NIC iletme ayarıLinux iletmesinden farklıdır. Bulut bayrağı, kaynağı veya hedefi NIC'ye atanmamış paketlere izin verir; net.ipv4.ip_forward ayarını açmaz ve konuk ayarı bulut iznini vermez.

Tünel soketinin kendi kaynak kararı vardır

wg-quick altındaki WireGuard Address ayarı, WireGuard arayüzüne bir adres atar; bu, dış UDP bağlama talimatı değildir. Şifreli soketin kaynağı rota tablosunu izler, bu nedenle bir ilke rotası veya ikinci bir varsayılan rota, arayüz adresine dokunmadan onu taşıyabilir.OpenVPN: local seçeneği ve UDP multihome aynı şekilde davranır: dinleyiciyi ve yanıtlarını ilgilendirirler, iletilen her istemcinin internet kaynağını değil.

Tüneli taşıyan alt katman rotasını koruyun ve istemcinin beklenen giriş düzeninden hâlâ kimliği doğrulanmış yanıtlar aldığını doğrulayın. Adres listesi sırasına kalıcı bir kaynak seçimi ilkesi olarak güvenmeyin, çünkü NIC'ye eklenen sonraki adres hangisinin kazanacağını değiştirebilir.

Neyi, hangi sırayla kabul etmeli

Üç sonucu ayrı ayrı kabul edin. Birincisi, harici bir istemci amaçlanan VPN girişine ulaşır. İkincisi, o VPN istemcisinden gelen yeni izinli bir istek belgelenmiş internet çıkışından ayrılır. Üçüncüsü, amaçlanmayan dinleyici ve iletme yolları reddedilmiş kalır. Genelden özele eşlemeleri ve her kararın konuk ve bulut sorumlularını aynı yerde kaydedin.

Başarılı bir tünel yalnızca ilk kısmı kanıtlar. Çıkışı yeni bir akışla test edin, çünkü önbelleğe alınmış bir bağlantı rota değiştikten çok sonra eski kaynağı kullanmaya devam edebilir.