Azure peering mi, VNet'ten VNet'e VPN mi? Yönlendirmeden önce karar verin

Azure size iki sanal ağı bağlamanın en az iki yolunu sunar ve bunlar aynı nesne üzerinde birbirinin yerine geçen ayarlar değildir. Peering, VNet'leri Microsoft'un omurgasında ağ geçidi olmadan birleştirir; VNet'ten VNet'e VPN ise sizin dağıttığınız, boyutlandırdığınız ve izlediğiniz iki ağ geçidi arasına bir IPsec ilişkisi koyar. Karar üç koşula indirgenir ve bir yol eklemeden önce üçüne de yanıt veremiyorsanız, hiç seçmediğiniz bir model için dolambaçlı bir çözüm kurmak üzeresiniz.

Modeli belirleyen üç koşul

Birincisi, gereksinimdeki bir şeyin sizin sahip olduğunuz ve işaret edebileceğiniz bir IPsec sınırına ihtiyaç duyup duymamasıdır. İkincisi, adres uzaylarının temiz olup olmadığı ve iki VNet'in yalnızca birbiriyle konuşması gerekip gerekmediğidir. Üçüncüsü, herhangi bir geçiş yolunun ve ağ geçidi faturasının kime ait olduğudur. Bu sırayla yanıtlayın, çünkü birinci koşul, ikinci ne kadar çekici görünürse görünsün peering'i dışlayabilir.

İki modelin ortak noktası katı bir adresleme kuralıdır: VNet adres uzayları çakışamaz. Ne peering ne de VNet'ten VNet'e VPN, iki özdeş aralığı belirsizlikten kurtarmanın desteklenen bir yolu değildir ve çakışma farklı bir bağlantı türü değil, bir eşleme tasarımı ya da yeniden tasarım gerektirir.

Koşul 1: sizin sahip olduğunuz bir IPsec sınırına ihtiyacınız var mı?

Peering trafiği Azure'un özel omurgası üzerinden taşır ve peered bağlantının kendisi için VPN ağ geçidi gerektirmez. Bu bir taşıma ifadesidir, denetçiye «biz IPsec çalıştırıyoruz» diye verilebilecek bir şifreleme ifadesi değildir. Gereksinim, müşterinin yapılandırdığı bir tüneli, belirli bir IKE ilkesini veya sizin denetlediğiniz donanımda sonlanan bir sınırı adlandırıyorsa, omurga ne kadar özel olursa olsun peering bunu karşılamaz.

VNet'ten VNet'e VPN o sınırı sağlar: iki ağ geçidi, bir IPsec/IKE ilişkisi, paylaşılan anahtarlar ve bununla gelen tüm operasyonel yüzey. Tünel durumunu, ağ geçidi kapasitesini, SKU sınırlarını ve tünelin ayakta olduğunu kanıtlayan izlemeyi devralırsınız. Gereksinim tam olarak o sınıra ilişkinse doğru yanıt budur ve o sınır peering genel bakışında peering'den ayrı bir bağlantı türü olarak açıklanır.

Diğer yönde de aynı ölçüde dikkatli olun. «VNet'ler arasında şifreleme gerekiyor» çoğu zaman iş yükünün kendi TLS'i ile karşılanır ve o zaman ağ geçidi arkasında gereksinim olmayan bir maliyettir. Mekanizmayı seçmeden önce denetçinin okuyacağı cümleyi yazın.

Koşul 2: topoloji doğrudan mı, yoksa bir şeyin geçmesi mi gerekiyor?

Peering geçişken değildir. Bir hub'a peered edilen iki VNet bununla birbirine bağlanmış olmaz ve tek yönde çalışıyor gibi görünen bir yol genellikle yalnızca bir tarafta Connected'a ulaşan bir peering'dir. İki taraf da var olmalı ve ikisi de Connected göstermelidir; trafik sessizce kaybolduğunda ilk kontrol edilen budur.

Gereksinim hub üzerinden şirket içi erişimse, ağ geçidi geçişi belirli rolleri olan ayrı bir tasarımdır: hub ağ geçidine sahiptir, spoke peering'i ağ geçidi geçişine izin verir ve spoke iletilen trafiğe izin vermelidir. Bunlar peering üzerindeki özelliklerdir, VNet'leri bağlamanın otomatik sonuçları değildir:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Etkin yol tablosu «yol var mı?» sorusunun dürüst yanıtıdır. Platformun gerçekte kullanacağı sonraki atlama türünü gösterir, bu yüzden yapılandırılmış görünen ama bağlı olmayan bir peering gizem olarak değil, eksik ya da yanlış yol olarak görünür.

Koşul 3: geçiş yolu ve fatura kime ait?

Her ek atlamanın bir sahibi vardır. Peering'de yeni bir VNet, her iki tarafta yeni bir peering çifti ve geçiş için trafiği iletmeye devam eden bir hub ile ona işaret etmeye devam eden bir yol tablosu demektir. VPN'de yeni bir VNet, başka bir ağ geçidi ya da var olan bir ağ geçidi üzerinde başka bir bağlantı demektir ve kendi kapasite tavanı izlenmelidir.

Maliyet aynı biçimi izler ama aynı kalemleri değil: peering ücretleri bağlantı ve veri aktarımıdır, VPN ise ağ geçidi saatlerini ve kendi aktarım ücretlerini ekler. Gerçekten bir yıl boyunca çalıştıracağınız topoloji için toplamı karşılaştırın; ikinci tünel ve izleme dahil, bugünkü tek bir bağlantının fiyatı değil. Kimsenin faturalamadığı işi de ekleyin: birinin anahtarları döndürmesi, tünel durumunu izlemesi ve ağ geçidi yeniden başladığında gece üçte uyarıya yanıt vermesi gerekir. Genellikle tartışmayı bu kalem belirler, çünkü teklifte asla görünmeyen tek kalem odur.

Ne seçerseniz seçin üç akışı test edin: amaçlanan, reddedilmiş olarak kalması gereken reddedilen ve hub ağ geçidinin ya da bir peering'in kapalı olduğu kurtarma durumu. Yalnızca mutlu yolu açıklayan bir model doğrulanmamıştır, gösterilmiştir.

Seçimi kendi iddiasına karşı doğrulayın

Modeli, sınırı ve sahibi adlandıran bir cümle yazın, ardından dağıtılan durumun buna uyduğunu kontrol edin. Peering için bu, her iki peering durumunun Connected olması, etkin yolun hedef öneki için peering sonraki atlamasını göstermesi ve yolda ağ geçidi olmaması demektir. VNet'ten VNet'e VPN için bu, her iki bağlantının Connected olması, her iki ağ geçidinde eşleşen anahtarlar ve ilkeler ve sonraki atlaması sanal ağ geçidi olan bir yol demektir.

Kontroller cümleyle çelişiyorsa önce cümleyi düzeltin. Bu tasarımlardaki karışıklığın çoğu kimsenin tanımlamadığı bir melezden gelir: iş yükü alt ağı için peering, bir eski hizmet için VPN ve sessizce birini tercih eden bir yol tablosu.