Peering ile bağlanan Azure VNet kendi VPN ağ geçidine ihtiyaç duyar mı?
Peering ile bağlanan bir VNet, desteklenen bir SKU ve her peering yönünde bir ayarla hub'ın VPN ağ geçidini kullanabilir. Peering durumunu değil, etkin rotaları doğrulayın.
Yeni bir spoke VNet ortaya çıkar, hub'ın zaten çalışan bir site-to-site ağ geçidi vardır ve bariz soru ikinci bir ağ geçidi için ödeme yapmanız gerekip gerekmediğidir. Genellikle hayır: ağ geçidi geçişi, spoke'un hub'ın ağ geçidini peering üzerinden kullanmasını sağlar. Bunun çalışıp çalışmayacağını üç koşul belirler ve hiçbiri peering durum rozetinde görünmez. Peering bağlantısı ve başkasının ağ geçidini kullanma izni ayrı ayarlardır, bu yüzden birbirine zaten ping atabilen iki VM, VPN yolu hakkında hiçbir şey kanıtlamaz.
Birinci koşul: ağ geçidi ve spoke'ta ağ geçidinin olmaması
Azure, Basic dışındaki VPN Gateway SKU'ları için ağ geçidi geçişini destekler ve hem bölgesel hem de genel peering bunu taşıyabilir. Spoke, sahip olmadığı bir ağ geçidini kullanır, dolayısıyla kendi ağ geçidine sahip olamaz: spoke'ta zaten bir ağ geçidi varsa veya uzak ağ geçidi seçeneği zaten seçiliyse, istediğiniz geçiş ayarı kullanılamaz veya etkisiz olur. Herhangi bir şeyi hata ayıklamadan önce bunu kontrol edin, çünkü devre dışı onay kutusu belirtidir, arıza değildir. Önce SKU'yu ve mevcut ağ geçidini okuyun, sonra peering ayarlarına bakın.
Seçeneğin görünmesi için mevcut spoke ağ geçidini, ona neyin bağlı olduğunu öğrenene kadar silmeyin. Geçiş sırası onay kutusundan daha önemlidir.
İkinci koşul: her peering yönünde bir ayar
Peering iki nesnedir, her VNet'te bir tane ve geçiş ayarları bu çiftin farklı taraflarında bulunur. Hub'ın spoke'a doğru peering'i, hub ağ geçidinin spoke'a hizmet vermesine izin vermelidir; spoke'un hub'a doğru peering'i hub'ın ağ geçidini kabul etmelidir. Microsoft'un ağ geçidi geçişi kılavuzu bunları yöne göre adlandırır ve doğru tutmanın tek yolu budur:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote etiketli bir kontrol, hangi VNet'in peering'ini düzenlediğinize bağlı olarak anlam değiştirir, bu yüzden kelimeyi değil yönü okuyun. İki tarafı da ayarlayın, kaydedin ve peering'in her iki yerde de bağlı olarak bildirildiğini doğrulayın.
Üçüncü koşul: adres alanı ve izin sınırları
Geçiş, aynı hedef önekinin iki ağ anlamına gelmesini sağlayamaz, bu yüzden hub, spoke ve yerel ağ aralıkları bunlardan herhangi biri çalışmadan önce ayrık olmalıdır. VNet'ler farklı aboneliklerde veya farklı kiracılarda da olabilir; bu bir yasak değildir, ancak her peering'i oluşturan veya güncelleyen kimliğin o ağda gereken izinlere sahip olması gerekir. Abonelikler arası değişiklikler genellikle izin nedeniyle başarısız olur ve hata topoloji sorunu olarak yanlış okunmaya elverişlidir.
Değişiklikten önce aralıkları ve sahipleri yazın. İkisinden birini tahmin etmek, bağlanan ama hiçbir şeyi yönlendirmeyen bir peering üretir.
Peering durumuyla değil, etkin rotalarla doğrulayın
Bir spoke iş yükünün ağ arabirimindeki etkin rotalara bakın ve gerçek yerel öneki bulun. Alt ağın rota tablosunu ve ağ geçidi rota yayılımının devre dışı olup olmadığını kontrol edin, çünkü kullanıcı tanımlı bir rota veya bir denetim cihazı, peering bayraklarının önerdiği yolu geçersiz kılabilir. Ardından karşı yönü doğrulayın: yerel ağ, spoke önekine site-to-site bağlantısı üzerinden nasıl ulaşacağını bilmelidir; bu, öğrenilen duyurularla veya açık bir rota ve müşteri cihazındaki eşleşen korumalı ağ girdisiyle olabilir. Önek herhangi bir tarafta eksikse, değiştirilmesi gereken şey peering bayrakları değildir.
Bir spoke iş yükünden bir hizmeti test edin ve yanıtı izleyin. VPN ağ geçidinden veya bir hub VM'inden yapılan test farklı bir kaynak öneki ve farklı bir yol kullanır.
Topoloji point-to-site istemcilerine de hizmet veriyorsa, bunların yüklü rotalarını ayrıca doğrulayın. Windows istemci paketlerinin topoloji değişikliğinden sonra yeniden oluşturulması gerekebilir, ve bu istemci tarafı yönlendirme işidir, ağ geçidi paylaşımının başarısız olduğunun kanıtı değildir.
Ağ geçidi paylaşmanın vermediği şey
Ağ geçidi geçişi bir yönlendirme kolaylığıdır, yetkilendirme değildir. Ağ güvenlik grupları, yerel filtreler ve hizmet düzeyi kuralları bir spoke iş yükünün neye ulaşabileceğine hâlâ karar verir, bu yüzden paylaşılan tünelin arkasındaki her şeye izin verdiğini varsaymak yerine belirli kaynak-hedef hizmetini etkinleştirin.
Peering de insanların umduğu şekilde geçişli değildir. Başka bir spoke veya özel bir uç nokta eklemek, mevcut geçiş ayarının kapsamadığı kendi yönlendirme ve erişim gereksinimlerini getirir.