İki şirket içi VPN adresi: iki Azure eşi, bir değil

Diyagramda şubede iki internet bağlantısı ve Azure'da bir VPN geçidi var, bu yüzden yerel ağ geçidi her iki genel adresi alır. Düzenli görünüyor ve diyagramın ima ettiği gibi çalışmıyor. Her şirket içi VPN cihazı ayrı bir eş ilişkisidir ve Microsoft'un çok cihazlı tasarımı her birine kendi yerel ağ geçidi kaynağını ve kendi bağlantısını verir. Tek bir kaynağa ikinci adres eklemek ikinci bir eş oluşturmaz. İki cihazın hiçbirini düzgün tanımlamayan bir kaynak oluşturur.

Efsane: bir geçit, iki adres

Yerel ağ geçidi uzak bir eşin tanımıdır: bir genel uç nokta ve arkasındaki özel önekler. Bu kaynağın «bu iki cihazdan herhangi biri» anlamına gelmesini sağlayan desteklenen bir yol yoktur.

Aynı karışıklık ters yönde de vardır; burada iki genel Azure IP'si iki Azure geçidinin varlığının kanıtı olarak okunur.

Nesneleri sayın, sonra tünelleri

Aynı özel ağlara erişimi ve kendi genel adresi olan bağımsız olarak işletilen iki şirket içi cihaz, ayrıca etkin-etkin modda bir yönlendirme tabanlı Azure geçidi alın. Azure geçidinin ayrı genel IP'lere sahip iki etkin örneği vardır. Her şirket içi cihaz iki örneğe de bağlanır. Bu tam ağdır ve nesne sayısı diyagramdan değil, bundan çıkar.

Aritmetik tasarım belgesine yapıştırılacak kadar kısa:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Bir bağlantı kaynağı birden fazla temel tünel taşıyabilir, bu yüzden dört tünel dört sanal ağ geçidi anlamına gelmez. İki genel Azure IP'si de uzak siteyi tanımlayan iki yerel ağ geçidiyle aynı nesneler değildir.

Etkin-etkin Azure tarafında ne ekler

Etkin-etkin, Azure geçidini bir etkin örnekten ikiye çevirir, her birinin kendi genel IP'si vardır ve tam ağı mümkün kılan da budur. Tek bir akışın verimini ikiye katlamaz. İki cihaz aynı anda ilettiğinde şirket içi tarafın eşit maliyetli çoklu yol desteğine sahip olması gerekliliğini de ortadan kaldırmaz. Herhangi bir şey sağlamadan önce geçit modunu, SKU'yu ve uzak cihazın yeteneklerini doğrulayın.

Pasif bekleme modundaki bir geçit tamamen geçerli bir tasarımdır; yalnızca farklı bir tünel sayısı verir.

BGP iki yolu da kullanılabilir kılar

Çok cihazlı tasarım için iki şirket içi cihaz da BGP çalıştırır. Her birine benzersiz bir BGP eş adresi verin ve aynı amaçlanan özel önekleri ilgili yollar üzerinden duyurun. Özel önekler korunan ağları tanımlar, genel adresler ise şifrelenmiş taşıyıcı bağlantılarının nerede sona erdiğini tanımlar. İkisini karıştırmak, her tünelin açık ama yolların yanlış olduğu bir tasarım üretir.

Dönüş yönlendirmesini ve iki yoldan herhangi birine dayanması gereken herhangi bir durum denetimini planlayın. Her uç noktada sağlıklı bir IKE oturumu, bir iş yükünün duyurulan her yolu kullanabileceğini kanıtlamaz.

Akış tabanlı seçim bant genişliği birleştirme değildir

Azure, akışın adreslemesi ve bağlantı noktaları üzerinde bir karma kullanarak akış başına bir yol seçer. Kararlı durumda, belirli bir TCP veya UDP akışının paketleri genellikle aynı tüneli kullanır ve şirket içi taraf dönüş yönü için başka bir tünel seçebilir. Bu nedenle iki cihaz ve dört tünel kullanılabilirliği artırır, tek bir aktarımın hızını değil. Bir satıcı slaytı birleştirme vaat ettiğinde, başka bir özelliği veya bir yanlış anlamayı anlatır.

Yolların nasıl dağıldığını görmek istiyorsanız paralel akışlarla, sınırı görmek istiyorsanız tek akışla test edin.

Gerçekte hangi yedekliliği kaldırdınız

Tek bir cihazdaki iki WAN adresi erişim bağlantısı seçeneklerini iyileştirir, ancak o cihazın gücünü, yazılımını ve arıza durumunu paylaşır. İki cihazla aynı şey değildirler ve Azure tarafındaki hiçbir yapılandırma bunu değiştirmez. Yedekliliği adres sayısından çıkarmak yerine satıcının desteklediği çift WAN veya küme tasarımını izleyin. Sonra test edin: her seferinde bir yolu kaldırın ve kalan yolları ve iki yönde gerçek uygulama alışverişini doğrulayın.

Algılama ve yakınsama gecikmeleri bekleyin ve bazı mevcut oturumların sona ereceğini bekleyin.