İki şube arasındaki trafiği Azure VPN ağ geçidi üzerinden yönlendirin
Tek bir Azure VPN ağ geçidinde iki Site-to-Site bağlantı şube trafiğini geçirebilir, ancak yalnızca her iki uç da öneki öğrendiğinde ve LAN'da dönüş yolu bulunduğunda.
İki şube, aralarında doğrudan bir tünel olmadan Azure VPN ağ geçidi üzerinden trafik alışverişi yapabilir. Her şube aynı ağ geçidine bir Site-to-Site bağlantı açar ve ağ geçidi öğrenilen önekleri iki bağlantı arasında iletir. Bunu çalıştıran ikinci tünel değil, rota alışverişidir: A şubesi B şubesinin önekini, B de A'nın önekini öğrenmelidir. Aşağıdaki denetimleri sırayla yapın ve ilk başarısız olanında durun, çünkü sonraki her adım ona bağlıdır.
Ön koşullar, herhangi bir şeyi yapılandırmadan önce
Bu tasarımın çalışıp çalışamayacağına dört koşul karar verir. Ağ geçidi rota tabanlı olmalıdır ve BGP destekleyen bir SKU üzerinde bulunmalıdır, iki bağlantıda da BGP etkin olmalıdır, şubelerin adres alanları çakışmamalıdır ve iki taraftan hiçbiri gerçek önekini gizlemek için NAT'a güvenmemelidir.
ASN'leri bilinçli planlayın. Azure'un belgelenmiş varsayılanı 65515'tir ve her şube yönlendiricisi ağ geçidiyle veya diğer şubeyle çakışmayan kendi özel ASN'ine ihtiyaç duyar. Mevcut bir ağ geçidi yapılandırmasını kontrol etmeden varsayılanı yeniden kullanmak, bir AS yolunun daha sonra reddedilmesinin yoludur.
Ayrıca VNet eşleme davranışını beklemediğinizi doğrulayın. Ağ geçidi yapılandırdığınız iki bağlantı arasında rota alışverişi yapar; rastgele eşlemeleri geçişli hale getirmez. Üçüncü bir ağ her iki şubeye ulaşacaksa kendi bağlantısına veya kendi rota yoluna ihtiyaç duyar, ağ geçidinin trafiği dağıtacağı varsayımına değil. İlk değişiklik penceresinden önce bu sınırı yazın, çünkü sonradan bir saha eklendiğinde insanların geri döndüğü tasarım kararı budur.
Bu sırayla yapılandırın
Her adımın gözlemlenebilir bir sonucu vardır, bu yüzden o görünene kadar ilerlemeyin.
- Sanal ağ geçidinde BGP'yi etkinleştirin ve ASN'si ile eş adresini not edin.
- Her şube için o şubenin gerçek adres alanı, ASN'si ve BGP eş adresiyle yerel bir ağ geçidi oluşturun.
- Her Site-to-Site bağlantıyı oluşturun ve BGP'yi bağlantının kendisinde etkinleştirin.
- Şube yönlendiricisini varsayımla ağ geçidinin genel IKE uç noktasıyla değil, Azure'un atadığı ağ geçidi adresiyle eşleşecek şekilde yapılandırın.
Dördüncü adım, çoğu denemenin tıkandığı yerdir. Azure'un bildirdiği BGP eş adresi, şube yönlendiricisinin komşu olarak kullanması gereken adrestir ve her zaman insanların tünel şemasından beklediği adres değildir.
Şubenin önekini kendisini duyurun, örneğin A'dan 10.10.0.0/16 ve B'den 10.20.0.0/16. Eksik belirli bir ağı kapatmak için varsayılan rota veya geniş bir toplu duyuru yapmayın; boşluk sonradan sessiz bir kara delik olarak geri döner.
Rota alışverişini iki uçta da doğrulayın
Bağlantı durumu denetim değildir. IPsec iki bağlantıda da çalışırken aralarında hiçbir önek geçmeyebilir. Ağ geçidinin BGP eşlerini ve öğrenilen rotalarını okuyun, ardından diğer şubeye doğru rotanın kullanılabilir bir yol olarak göründüğünü doğrulayın.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP tablosunda bulunan bir önek, iletme kararını yine de statik bir rotaya veya daha özel bir öneğe kaptırabilir. Yalnızca alınanı değil, seçilen rotayı denetleyin.
LAN tarafında dönüş yolunu izleyin
Azure'da doğru görünen ve sahada başarısız olan kısım burasıdır. A şubesindeki bir ana bilgisayar paketini A'nın VPN yönlendiricisine yalnızca o yönlendirici varsayılan ağ geçidiyse veya ana bilgisayar ya da ağ geçidi B öneği için bir rotaya sahipse gönderir. Aynı şey diğer yönde de geçerli olmalıdır.
Ayrı bir çekirdek anahtar LAN'ın varsayılan ağ geçidiyse, VPN yönlendiricisine işaret eden diğer şubeye doğru rotaya ihtiyaç duyar. O olmadan istek ulaşır ve yanıt internet yolundan çıkar, kullanıcı açılan ve sonra askıda kalan bir bağlantı görür.
Bunu düzeltmek için ağ geçidi alt ağındaki bir ağ güvenlik grubuna başvurmayın. O alt ağın kendi gereksinimleri vardır ve oradaki bir NSG şube tarafı ilkesinin desteklenen bir yerine geçişi değildir. Filtreleme şubelerin güvenlik duvarlarına ve iş yüklerinin kendisine aittir; kurallar orada sahipleri tarafından gözden geçirilebilir. Bu kuralları alt ağ NSG'sine taşımak, onları bir sonraki arızayı ayıklayacak ekipten de gizler.
İşleme izin verin, sonra reddedilen bir testle kanıtlayın
Öğrenilen rota izin değildir. Gerçekten ihtiyaç duyduğunuz kaynak, hedef ve hizmete şubelerin güvenlik duvarları ve uç nokta ilkesi üzerinden izin verin, geri kalanını reddedilmiş bırakın.
A şubesindeki sıradan bir iş yükünden B şubesindeki gerçek bir hizmete test edin, yanıtı doğrulayın, sonra yasak kalması gereken bir işlemi deneyin. VPN cihazının kendisinin ürettiği trafik farklı bir kaynak adres kullanabilir ve LAN yönlendirme aşamasını atlayabilir, bu yüzden yönlendiriciden başarılı bir ping göründüğünden daha azını kanıtlar.
Dört olguyu yazarak bitirin: değiş tokuş edilen önekler, kullanılan ASN'ler, her tarafın LAN dönüş yolu ve hizmete izin veren ilke. Bunlardan biri eksikse kurulum ilk değişikliğe kadar çalışır ve sonra kimse nedenini açıklayamaz.