- Ana Sayfa
- /
- Makale
Özel Örnek-Sanal Bağlantı
Sanal Bağlantı, Webex Calling Özel Bulut Sunucusuna Bulut Bağlantısı için ek bir eklenti seçeneğidir. Virtual Connect, Müşterilerin noktadan noktaya IP VPN Tünellerini kullanarak Özel Ağlarını internet üzerinden güvenli bir şekilde genişletmelerini sağlar. Burada Virtual Connect için sipariş verme, aktivasyon ve yapılandırma hakkında tartışıyoruz.
Giriş
Sanal Bağlantı, Webex Calling (Adanmış Bulut Sunucusu) için Bulut Bağlantısı için ek bir eklenti seçeneğidir. Virtual Connect, Müşterilerin noktadan noktaya IP VPN Tünellerini kullanarak Özel Ağlarını internet üzerinden güvenli bir şekilde genişletmelerini sağlar. Bu bağlantı seçeneği, mevcut Müşteri Tesisi Ekipmanı (CPE) ve internet bağlantısını kullanarak Özel Ağ bağlantısının hızlı bir şekilde kurulmasını sağlar.
Cisco, hizmetin gerekli olduğu Cisco'nun Özel Bulut Sunucusu veri merkezi bölgelerinde yedekli IP VPN Tünellerini ve gerekli İnternet erişimini barındırır, yönetir ve garanti eder. Benzer şekilde, Yönetici, Virtual Connect kurulumu için gerekli olan ilgili CPE ve İnternet hizmetlerinden sorumludur.
Belirli bir Özel Bulut Sunucusu bölgesindeki her Sanal Bağlantı sırası, seçilen Bölgedeki her Cisco'nun veri merkezine birer tane olmak üzere, IPsec şifrelemesi (IPsec üzerinden GRE) ile korunan iki genel yönlendirme kapsülleme (GRE) tüneli içerir.
Virtual Connect, tünel başına 250 Mbps bant genişliği sınırına sahiptir ve daha küçük dağıtımlar için önerilir. İki noktadan noktaya VPN tüneli kullanıldığından, buluta giden tüm trafiğin müşteri ana uç CPE'sinden geçmesi gerekir ve bu nedenle çok sayıda uzak sitenin olduğu yerlerde uygun olmayabilir. Diğer alternatif eşleme seçenekleri için bkz. Bulut Bağlantısı.
Sanal Bağlantı için eşleştirme isteğini göndermeden önce, ilgili bölgede Özel Bulut Sunucusu hizmetinin etkinleştirildiğinden emin olun.
Önkoşullar
Sanal Bağlantıyı kurmak için ön koşullar şunları içerir:
-
Müşteri sağlar
-
Dağıtımı desteklemek için yeterli bant genişliğine sahip İnternet bağlantısı
-
İki IPsec tüneli için genel IP adresi (ler)
-
İki GRE tüneli için müşteri tarafı GRE taşıma IP adresleri
-
-
İş Ortağı ve Müşteri
-
Bant genişliği gereksinimlerini değerlendirmek için birlikte çalışın
-
Ağ aygıtlarının Sınır Ağ Geçidi Protokolü (BGP) yönlendirmesini ve IPsec tünel tasarımını GRE üzerinden desteklediğinden emin olun
-
-
İş Ortağı veya Müşteri sağlar
-
Siteden siteye VPN tünel teknolojileri bilgisine sahip ağ ekibi
-
BGP, eBGP ve genel yönlendirme ilkeleri hakkında bilgi sahibi ağ ekibi
-
-
Cisco
-
Cisco, GRE tünel arayüzleri için özel otonom sistem numaraları (ASN'ler) ve geçici IP adresleme atadı
-
Cisco, Özel Bulut Sunucu Bulut adreslemesi için genel ancak İnternet yönlendirilemez Sınıf C (/24) ağı atadı
-
Bir müşterinin yalnızca 1 CPE cihazı varsa, her bölgedeki Cisco'nun veri merkezlerine (DC1 ve DC2) giden 2 tünel o CPE cihazından olacaktır. Müşterinin ayrıca 2 CPE cihazı seçeneği vardır, daha sonra her CPE cihazı her bölgedeki yalnızca Cisco'nun Veri Merkezlerine (DC1 ve DC2) giden 1 tünele bağlanmalıdır. Her bir tünelin Müşterinin altyapısı içindeki ayrı bir fiziksel sahada/lokasyonda sonlandırılmasıyla ek yedeklilik elde edilebilir.
Teknik Detaylar
Dağıtım modeli
Virtual Connect, yönlendirme ve GRE kontrol düzlemlerinin bir cihaz tarafından sağlandığı ve IPsec kontrol düzleminin başka bir cihaz tarafından sağlandığı çift katmanlı bir ana uç mimarisi kullanır.
Sanal Bağlantı bağlantısı tamamlandıktan sonra, Müşterinin kurumsal ağı ile Özel Bulut Sunucusu Cisco'nun veri merkezleri arasında IPsec üzerinden iki GRE t üneli oluşturulacaktır. İlgili Bölgedeki her yedekli veri merkezine bir tane . Eşleştirme için gerekli olan ek ağ öğeleri, İş Orta ğı veya Müşteri tarafından Control Hub Sanal Bağlantı etkinleştirme formu aracılığıyla Cisco'ya değiştirilir.
Aşağıdaki şekil, müşteri tarafındaki 2 yoğunlaştırıcı seçeneği için sanal bağlantı dağıtım modeli örneğini göstermektedir.
Sanal Bağlantı - VPN, Müşterinin Hub Sitelerinin belirli bir bölgedeki Özel Bulut Sunucunun veri merkez lerinin DC1 ve DC2'sine bağlı olduğu bir Hub tasarımıdır.
Daha iyi yedeklilik için iki Hub sitesi önerilir, ancak iki tünelli One Hub sitesi de desteklenen bir dağıtım modelidir.
Tünel başına bant genişliği 250 Mbps ile sınırlıdır. Etkili yük devretmesini sağlamak için, her iki tüneldeki birleşik trafik 250 Mbps'yi geçmemelidir, çünkü bir arıza durumunda tüm trafik tek bir tünelden yönlendirilecektir.
Müşterinin aynı bölgedeki uzak sitelerinin, Müşterinin WAN'ı üzerinden Hub sitelerine geri bağlanması gerekir ve bu bağlantı için Cisco'nun sorumluluğu değildir.
İş ortaklarının Müşterilerle yakın bir şekilde çalışması ve Sanal Bağlantı hizmeti bölgesi için en uygun yolun seçilmesini sağlaması beklenir.
Aşağıdaki şekil, Özel Bulut Sunucusu bulut bağlantısı eşleştirme bölgelerini göstermektedir.
Yönlendirme
Sanal Bağlantı eklentisi için Yönlendirme, Adanmış Bulut Sunucusu ile Müşteri Tesisi Ekipmanı (CPE) arasında harici BGP (eBGP) kullanılarak uygulanır. Cisco, bir bölgedeki her yedekli DC için ilgili ağlarını Müşterinin CPE'sine ilan eder ve CPE'nin CISCO'ya varsayılan bir rota reklamını yapması gerekir.
-
Cisco bakımını yapar ve atanır
-
Tünel Arabirimi IP adresleme (yönlendirme için geçici bağlantı) Cisco, belirlenmiş bir Paylaşılan Adres Alanından atar (herkese açık olmayan)
-
Tünel taşımacılığı seçim adresi (Cisco tarafı)
-
Müşteri BGP yönlendirme yapılandırması için özel otonom sistem numaraları (ASN'ler)
-
Cisco, belirlenen özel kullanım aralığından atamalar: 64512 - 65534
-
-
-
EbGP, Özel Bulut Sunucusu ve CPE arasında yol alışverişi yapmak için kullanılır
-
Cisco, atanan /24 ağını ilgili bölgedeki her DC için 2/25'e böler
-
Virtual Connect'te her /25 ağı, ilgili noktadan noktaya VPN tünelleri üzerinden Cisco tarafından CPE'ye geri ilan edilir (geçici bağlantı)
-
CPE, uygun EBGP komşularıyla yapılandırılmalıdır. Bir CPE kullanılıyorsa, biri her uzak tünele işaret eden iki eBGP komşusu kullanılacaktır. İki CPE kullanıyorsanız, her CPE'nin CPE için tek uzak tünele odaklanan bir eBGP komşusu olacaktır.
-
Her GRE tünelinin Cisco tarafı (tünel arabirimi IP) CPE'deki BGP komşusu olarak yapılandırılmıştır
-
Tünellerin her biri üzerinde varsayılan bir rota reklamını yapmak için CPE gereklidir
-
CPE, müşterinin kurumsal ağı içinde öğrenilen yolları gerektiğinde yeniden dağıtma konusunda sorumludur.
-
-
Arızasız bağlantı hatası koşulu altında, tek bir CPE iki aktif/aktif tünele sahip olacaktır. İki CPE düğümü için, her CPE'nin bir aktif tüneli olacaktır ve her iki CPE düğümü de aktif ve trafik geçmelidir. Arızasızlık senaryosunda, trafik doğru /25 hedeflere giden iki tünele bölünmelidir, tünellerden biri düşerse, kalan tünel her ikisi için de trafiği taşıyabilir. Böyle bir arıza senaryosunda, /25 ağı kapalı olduğunda, /24 ağı yedek yol olarak kullanılır. Cisco, bağlantı kesen DC'ye dahili WAN üzerinden müşteri trafiğini gönderecektir.
Sanal bağlantı trafik akışı
Her iki tünel açıldığında trafik akışı

Bu görüntü, hem birincil hem de ikincil tüneller çalışır durumdayken trafik akışını detaylandıran bir Virtual Connect ağ mimarisini göstermektedir.
Bir müşterinin Cisco'nun veri merkezlerinde barındır ılan UC uygulamalarına erişmesi için aktif bir bağlantı modelini temsil eder ve rota değişimi için BGP ile internet üzerinden çift GRE/IPSEC tünellerinden yararlanır.
Tanımlar:
- Müşteri Önerisi:
- Bu, kullanıcıların ve cihazlarının (örn. IP telefonları, UC istemcileri çalıştıran bilgisayarlar) bulunduğu müşterinin yerinde ağını temsil eder.
- Buradan gelen trafiğin, Cisco'nun veri merkezlerinde barındırılan UC uygulamalarına ulaş ması gerekir.
- Cisco Webex CallingÖzel Bulut Sunucusu (Özel Bulut Sunucusu) veri merkezleri (WXC-Di DC-
A ve wxC-Di DC-B):
- Bunlar, UC uygulamalarını barındıran Cisco'nun veri merkezleridir.
- DC-A ve DC-B coğrafi olarak farklıdır ve yede klilik sağlar.
- Her veri merkezinin UC uygulamaları için kendi alt ağı vardır:
- DC-A alt ağı: X.X.X.0/25
- DC-B Alt Ağı: X.X.128/25
- GRE/IPsec Tünelleri (Tünel 1 ve Tünel 2):
- Bunlar, genel internet üzerinden müşteri tesisi ile Cisco veri merkezi arasındaki güvenli, şifreli bağlantılardır.
- GRE (Genel Yönlendirme Kapsülleme): Bu protokol, sanal noktadan noktaya bağlantılar içindeki çeşitli ağ katmanı protokollerini kapsüllemek için kullanılır. BGP gibi yönlendirme protokollerinin tünel üzerinde çalışmasına izin verir.
- IPsec (İnternet Protokolü Güvenliği): Bu protokol paketi, IP iletişimi için şifre leme güvenlik hizmetleri (kimlik doğrulama, bütünlük, gizlilik) sağlar. GRE-kapsüllenmiş trafiği şifreleyerek İnternet üzerinden güvenli veri iletimi sağlar.
- Sınır Geçidi Protokolü (BGP):
- BGP, müşteri tesisi ve Cisco veri merkez leri arasında yönlendirme bilgilerini alışverişinde bulunmak için kullanılan yönlendirme protokolüdür.
Yukarıdaki şemada gösterildiği gibi, müşteri tesislerinde dağıtılan cihazların iki GRE/IPSEC tüneli kurması gerekir.
Aşağıda XX/YY, DC-A DC-B ile kullanılan adlandırma kuralları, Özel Bulut Sunucusunun sunulduğu tüm bölgeler için geneldir. Bu değerler her bölge için benzersiz ve her bölge için gerçek değerler olacaktır. Sanal bağlantının etkinleştirilmesi sırasında belirli değerler sağlanır.
Cisco tarafında IPsec ve GRE tünelleri farklı cihazlarda sonlandırılacaktır. Bu nedenle müşteri, cihazlarda IPsec hedef ve GRE hedef IP'lerini buna göre yapılandırdığından emin olmalıdır. Müşteriler, cihaz larında destekleniyorsa, GRE ve IPSEC için aynı IP'yi kullanabilir. Yukarıdaki şemaya bakın. IP ile ilgili değerler, portaldaki sanal bağlantının etkinleştirilmesi sırasında sağlanır.
- Tünel 1: Müşteri tesisini İnternet üzerinden “Özel Bulut Sunucusu DC-A"ya (Veri Merkezi A) bağlar. Bu tünel müşteri tarafında BGP AS:64XX1 ve Özel Bulut Sunucusu DC-A tarafında BGP AS: 64XX2 kullanır. IPSEC ve GRE tünel kaynak yapılandırmaları, müşteri tarafından sağlanan ve Cisco tarafından sağ lanan ayrıntılar arasında bölünmüştür.
- Tünel 2: Müşteri tesisini İnternet üzerinden “Özel Bulut Sunucusu DC-B"ye (Veri Merkezi B) bağlar. Bu tünel müşteri tarafında BGP AS:64YY1 ve Özel Bulut Sunucusu DC-B tarafında BGP AS: 64YY2 kullanır. Tünel 1 gibi, IPSEC ve GRE tünel kaynak yapılandırmaları da müşteri ve Cisco arasında paylaşılır.
BGP'de AS: 64XX ve BGP AS: 64YY, XX ve YY belirli bir bölgeye özgüdür.
GRE/IPSEC tünelleri Özel Bulut Sunucusu veri merkez Webex Calling lerine (A ve B) kurulduktan sonra, müşteri ilgili BGP oturumları üzerinden Cisco'dan reklamı yapılan aşağıdaki yolları almalıdır.
- DC-A için: Cisco'dan reklamı yapılan rotalar X.X.0/25 ve X.X.0/24 olacaktır. İsteğe bağlı olarak IaaS müşteri rotaları için istenirse ve yapılandırılırsa YY.Y.0/25 ve Y.Y.Y.0/24 Cisco'dan ilan edilecektir.
- DC-B için: Cisco'dan reklamı yapılan yollar X.X.128/25 ve X.X.X.0/24 olacaktır. İsteğe bağlı olarak , müşteri rotaları için IaaS istenirse ve yapılandırılırsa, Y.Y.128/25 ve Y.Y.Y.0/24 Cisco'dan ilan edilecektir.
- Müşterinin her iki bağlantı (tüneller) üzerinden Cisco'ya 0.0.0./0 rotasını tanıtması gerekir
- Müşteri, her iki tünel açıldığında ilgili tünellerden Cisco'ya trafik göndermek için en uzun önek (/25) rotalarını takip etmelidir.
- Cisco trafiği simetrik tutmak için trafiği aynı tünellerden geri getirecek.
Trafik Akışı:
- Müşteri tesisinden “DC-A UC Uygulamaları” (X.X.0/25) için yönlendirilen trafik, Tünel 1'den geçer.
- Müşteri tesisinden “DC-B UC Uygulamaları” (X.X.128/25) için yönlendirilen trafik, Tünel 2'den geçmektedir.
Başarısızlık senaryosu: tünellerden biri çöktüğünde trafik akışı

Yukarıdaki şemada gösterildiği gibi, DC-A"ya giden tünel aşağı indiğinde, tünelden DC-A"ya kurulan bgp aşağı inecektir..
BGP Üzerindeki Et ki: Tünel 1 çöktüğünde, o tünel üzerindeki BGP oturumu da düşecektir . Sonuç olarak, DC-A artık rotalarını (özellikle X. X.0/25) müşteriye bu yol üzerinden reklamını yapamayacaktır. Bu nedenle müşteri yönlendiricisi yolu ulaşıl amaz olarak algılar.
Artık Tünel 1 kapalı olduğundan, müşteri tesisindeki müşteri yönlendiricisi, Tünel 1 üzerinden öğrenilen rotaları yönlendirme tablosundan otomatik olarak kaldıracak veya ulaşıl amaz olarak işaretleyecektir.
- UC Uygulama Ağı (X.X.0/24) veya DC-A alt ağı (X.X.0/25) için yönlendirilen trafik daha sonra çalışma tüneli vasıtasıyla, X.X.X.0/25 ağını içeren X.X.0/24 'ün reklamını yapmaya devam eden DC-B'ye yönlendirilecektir.
- DC-B'ye giden tünel kapalıyken DC-A'ya giden tünel hala yukarıdaysa benzer davranış görülecektir.
Bağlantı Süreci
| 1 | |
| 2 | |
| 3 | |
| 4 |
Adım 1: CCW Siparişi
Virtual Connect, CCW'de Özel Bulut Sunucusu için bir eklentidir.
| 1 |
CCW sipariş sitesine gidin ve ardından sitede oturum açmak için Oturum Aç"ı tıklayın: |
| 2 |
Tahmin Oluştur. |
| 3 |
“A-FLEX-3" SKU ekleyin. |
| 4 |
Seçenekleri düzenle'yi seçin. |
| 5 |
Görünen abonelik sekmesinde Seçenekler ve Eklentiler'i seçin. |
| 6 |
Ek Eklentiler altında, “Özel Bulut Sunucusu için Sanal Bağlantı” seçeneğinin yanındaki onay kutusunu işaretleyin. SKU adı “A-FLEX-DI-VC” dir. |
| 7 |
Sanal Bağlantının gerekli olduğu bölge miktarını ve sayısını girin. Sanal Bağlantı miktarı, Adanmış Bulut Sunucusu için satın alınan toplam bölge sayısını geçmemelidir. Ayrıca, bölge başına yalnızca bir Sanal Bağlantı siparişine izin verilir. |
| 8 |
Seçimlerinizden memnun kaldığınızda, Sayfanın sağ üst kısmındaki Doğrula ve Kaydet'i tıklayın. |
| 9 |
Siparişinizi tamamlamak için Kaydet ve Devam'ı tıklayın. Kesinleşmiş siparişiniz artık sipariş ızgarasında görünür. |
Adım 2: Control Hub'da Sanal Bağlantının Etkinleştirilmesi
| 1 |
Control Hub'da oturum açın https://admin.webex.com/login. |
| 2 |
Hizmetler bölümünde Arama > Özel Instacnce > Bulut Bağlantısı'na gidin. |
| 3 |
Sanal Bağlantı kartında, satın alınan Sanal Bağlantı miktarı listelenir. Yönetici artık Sanal Bağlantı etkinleştirmesini başlatmak için Etkinleştir'e tıklayabilir.
Etkinleştirme işlemi yalnızca “Müşteri Tam Yönetici” Rolü olan Yöneticiler tarafından tetiklenebilir. Oysa, “Müşteri salt okunur yönetici” Rolü olan bir yönetici yalnızca durumu görüntüleyebilir. |
| 4 |
Etkin leş tir düğmesine tıklandığında, Yöne ticinin Cisco tarafındaki eşleme yapılandırmaları için gereken Sanal Bağlantı teknik ayrıntılarını sağlaması için Sanal Bağlantıyı Etkinleş tir formu görüntülenir. Form ayrıca seçilen Bölgeye bağlı olarak Cisco tarafında statik bilgiler sağlar. Bu bilgiler, Müşteri yöneticilerinin Bağlantıyı kurmak için kendi taraflarında CPE'yi yapılandırmaları için yararlı olacaktır. |
| 5 |
Tüm zorunlu alanlar doldurulduktan sonra Etkinleştir düğmesine tıklayın. |
| 6 |
Belirli bir bölge için Sanal Bağlantı Etkinleştirme formu doldurulduktan sonra, müşteri etkinleştirme formunu Control Hub, Çağrı > Adanmış Örnek > Bulut Bağlantısı sekmesinden Dışa Aktar ayarlarına tıklayabilir.
Güvenlik nedenlerinden dolayı Kimlik Doğrulama ve BGP Şifresi Dışa Aktarılan belgede kullanılamaz, ancak yönetici Control Hub'ın altındaki Ayarları Görüntüle, Çağrı > Özel Örnek > Bulut Bağlantısı sekmesini tıklatarak bunları Control Hub'da görüntüleyebilir. |
Adım 3: Cisco Ağ Yapılandırmasını gerçekleştirir
| 1 |
Sanal Bağlantı Etkinleştirme formu tamamlandıktan sonra durum, Arama > Adanmış Bulut Sunucu > Bulut Bağlantısı Sanal Bağlantı kartı bölümündeki Etkinleştirme Devamında olarak güncellenecektir. |
| 2 |
Cisco, Cisco'nun yan ekipmanında gerekli yapılandırmaları 5 iş günü içinde tamamlayacaktır. Başarılı bir şekilde tamamlandığında, durum Control Hub'da söz konusu bölge için “Etkinleştirildi” olarak güncellenecektir. |
Adım 4: Müşteri Ağ Yapılandırmasını gerçekleştirir
|
Müşteri yöneticisine, Müşteri tarafından sağlanan girdilere göre IP VPN bağlantısı için Cisco'nun yapılandırmalarının tamamlandığını bildirmek için durum “Etkinleştirildi” olarak değiştirilir. Ancak, müşteri yöneticisinin CPE'lerdeki konfigürasyonların kendi tarafını tamamlaması ve Virtual Connect tünelinin Çevrimiçi olması için bağlantı yollarını test etmesi beklenir. Yapılandırma veya bağlantı sırasında karşılaşılan herhangi bir sorun olması durumunda, müşteri yardım Cisco TAC için iletişime geçebilir. |
Sorun giderme
IPsec İlk Aşama (IKEv2 Müzakere) Sorun Giderme ve Doğrulama
IPsec tünel anlaşması, IKEv2 aşaması ve IPsec aşaması olmak üzere iki aşamadan oluşur. IKEv2 aşama anlaşması tamamlanmazsa, ikinci bir IPsec aşaması başlatılmaz. İlk olarak, IKEv2 oturumunun etkin olup olmadığını doğrulamak için üçüncü taraf ekipmanında “crypto ikev2 sa göster” komutunu (Cisco ekipmanında) veya benzer bir komutu verin. IKEv2 oturumu aktif değilse, olası nedenler şunlar olabilir:
-
İlginç trafik IPsec tünelini tetiklemiyor.
-
IPsec tünel erişim listesi yanlış yapılandırılmış.
-
Müşteri ile Özel Bulut Sunucusu IPsec tüneli uç noktası IP'si arasında bağlantı yoktur.
-
IKEv2 oturum parametreleri, Özel Bulut Sunucu tarafı ile müşteri tarafı arasında eşleşmiyor.
-
Bir güvenlik duvarı IKEv2 UDP paketlerini engelliyor.
Öncelikle, IKEv2 tünel anlaşmasının ilerlemesini gösteren iletiler için IPsec günlüklerini kontrol edin. Günlükler, IKEv2 müzakeresinde nerede bir sorun olduğunu gösterebilir. Günlük kaydı mesajlarının olmaması, IKEv2 oturumunun etkinleştirilmediğini de gösterebilir.
IKEv2 müzakere ile ilgili bazı yaygın hatalar şunlardır:
-
CPE tarafındaki IKEv2 ayarları Cisco tarafıyla eşleşmiyor, belirtilen ayarları tekrar kontrol edin:
-
IKE sürümünün sürüm 2 olup olmadığını kontrol edin.
-
Şifreleme ve Kimlik Doğrulama parametrelerinin Adanmış Bulut Sunucusu tarafında beklenen şifrelemeyle eşleştiğini doğrulayın.
“GCM” şifresi kullanıldığında, GCM protokolü kimlik doğrulamasını işler ve kimlik doğrulama parametresini NULL olarak ayarlar.
-
Ömür boyu ayarını doğrulayın.
-
Diffie Hellman modül grubunu doğrulayın.
-
Sözde Rastgele İşlev ayarlarını doğrulayın.
-
-
Kripto haritasının erişim listesi şu şekilde ayarlanmamıştır:
-
İzin GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (veya eşdeğer komut)
Erişim listesi özellikle “GRE” protokolü için olmalıdır ve “IP” protokolü çalışmayacaktır.
-
Günlük iletileri IKEv2 aşaması için herhangi bir müzakere etkinliği göstermiyorsa, paket yakalama gerekebilir.
Adanmış Bulut Sunucu tarafı her zaman IKEv2 değişimini başlatmayabilir ve bazen müşteri CPE tarafının başlatıcı olmasını bekleyebilir.
IKEv2 oturumu başlatmak için aşağıdaki önkoşullar için CPE tarafı yapılandırmasını kontrol edin:
-
CPE tüneli taşıma IP'sinden Özel Bulut Sunucusu tüneli taşıma IP'sine GRE trafiği (protokol 50) için bir IPsec kripto erişim listesi olup olmadığını kontrol edin.
-
GRE tünel arayüzünün GRE keepalives için etkinleştirildiğinden emin olun, eğer ekipman GRE keepalives'i desteklemiyorsa, GRE keepalives varsayılan olarak Özel Bulut Sunucusu tarafında etkinleştirileceği için Cisco bilgilendirilir.
-
BGP'nin etkinleştirildiğinden ve Özel Bulut Sunucusu tüneli IP'sinin komşu adresiyle yapılandırıldığından emin olun.
Düzgün yapılandırıldığında, aşağıdakiler IPsec tüneli ve ilk aşama IKEv2 anlaşması başlatır:
-
GRE, CPE tarafındaki GRE tünel arayüzünden Özel Örnek tarafındaki GRE tünel arayüzüne gider.
-
CPE tarafındaki BGP komşusundan Özel Bulut Sunucu tarafındaki BGP komşusuna BGP komşusuna BGP komşusuna BGP komşusu BGP oturumu.
-
CPE yan tünel IP adresinden Özel Bulut Sunucusu yan tünel IP adresine ping.
Ping, tünel taşıma IP"si tünel taşıma IP"si olamaz, tünel IP"sine tünel IP"si olmalıdır.
IKEv2 trafiği için bir paket izleme gerekiyorsa, filtreyi UDP için ayarlayın ve bağlantı noktası 500 (IPsec uç noktalarının ortasında bir NAT aygıtı olmadığında) veya 4500 bağlantı noktası (IPsec uç noktalarının ortasına bir NAT aygıtı yerleştirildiğinde) ayarlayın.
500 veya 4500 bağlantı noktasına sahip IKEv2 UDP paketlerinin DI IPsec IP adresine gönderilip alındığını doğrulayın.
Özel Bulut Sunucusu veri merkezi her zaman ilk IKEv2 paketini başlatmayabilir. Gereksinim, CPE cihazının ilk IKEv2 paketini Özel Bulut Sunucusu tarafına doğru başlatabilmesidir.
Yerel güvenlik duvarı izin veriyorsa, uzak IPsec adresine de ping atmayı deneyin. Yerel IPsec adresinden uzak IPsec adresine ping işlemi başarılı olmazsa yardım etmek ve paketin nereye bırakıldığını belirlemek için bir izleme yolu gerçekleştirin.
Bazı güvenlik duvarları ve internet ekipmanları izleme rotasına izin vermeyebilir.
IPsec İkinci Aşama (IPsec Müzakere) Sorun Giderme ve Doğrulama
IPsec ikinci aşamasında sorun gidermeden önce IPsec birinci aşamasının (yani IKEv2 güvenlik ilişkilendirmesinin) etkin olduğunu doğrulayın. IKEv2 oturumunu doğrulamak için bir “crypto ikev2 sa göster” veya eşdeğer bir komut uygulayın. Çıktıda, IKEv2 oturumunun birkaç saniyeden uzun süredir devam ettiğini ve zıplamadığını doğrulayın. Oturum çalışma süresi oturum “Etkin Zaman” veya çıktıda eşdeğeri olarak gösterilir.
IKEv2 oturumu aktif ve aktif olarak doğrulandığında, IPsec oturumunu araştırın. IKEv2 oturumunda olduğu gibi, IPsec oturumunu doğrulamak için bir “crypto ipsec sa göster” veya eşdeğer bir komut gerçekleştirin. GRE tüneli kurulmadan önce IKEv2 oturumu ve IPsec oturumu etkin olmalıdır. IPsec oturumu etkin olarak gösterilmezse IPsec günlüklerinde hata iletileri veya anlaşma hataları olup olmadığını kontrol edin.
IPsec görüşmeleri sırasında karşılaşılabilecek daha yaygın sorunlardan bazıları şunlardır:
CPE tarafındaki ayarlar Özel Bulut Sunucu tarafıyla eşleşmiyor, ayarları tekrar kontrol edin:
-
Şifreleme ve Kimlik Doğrulama parametrelerinin Adanmış Bulut Sunucu tarafındaki ayarlarla eşleştiğini doğrulayın.
-
Perfect Forward Secrecy ayarlarını ve Adanmış Bulut Sunucu tarafındaki ayarların eşleştiğini doğrulayın.
-
Ömür boyu ayarlarını doğrulayın.
-
IPsec'in tünel modunda yapılandırıldığını doğrulayın.
-
Kaynak ve hedef IPsec adreslerini doğrulayın.
Tünel Arayüzü Sorun Giderme ve Doğrulama
IPSec ve IKEv2 oturumlarının açık ve etkin olduğu doğrulandığında, GRE tüneli keepalive paketleri Özel Örnek ve CPE tüneli uç noktaları arasında akabilir. Tünel arabirimi durumu göstermiyorsa, bazı yaygın sorunlar şunlardır:
-
Tünel arabirimi taşıma VRF'si, geri döngü arabiriminin VRF'si ile eşleşmiyor (tünel arabiriminde VRF yapılandırması kullanılıyorsa).
Tünel arabiriminde VRF yapılandırması kullanılmazsa, bu kontrol göz ardı edilebilir.
-
Keepalives, CPE yan tünel arayüzünde etkin değil
CPE ekipmanında keepalives desteklenmiyorsa, Adanmış Bulut Sunucusu tarafındaki varsayılan keepalives de devre dışı bırakılması için Cisco bilgilendirilmelidir.
Keepalives destekleniyorsa, keepalives etkinleştirildiğini doğrulayın.
-
Tünel arabiriminin maskesi veya IP adresi doğru değil ve Tahsis Edilmiş Bulut Sunucusu beklenen değerleriyle eşleşmiyor.
-
Kaynak veya hedef tünel aktarım adresi doğru değil ve Tahsis Edilmiş Bulut Sunucusu beklenen değerleriyle eşleşmiyor.
-
Bir güvenlik duvarı, GRE paketlerinin IPsec tüneline gönderilmesini veya IPsec tünelinden alınmasını engelliyor (GRE tüneli IPsec tüneli üzerinden taşınır)
Bir ping testi, yerel tünel arayüzünün çalışır durumda olduğunu ve bağlantının uzak tünel arabirimine iyi olduğunu doğrulamalıdır. Tünel IP'sinden (taşıma IP'sinden değil) uzak tünel IP'sine ping denetimi gerçekleştirin.
GRE tünel trafiğini taşıyan IPsec tüneli için kripto erişim listesi, yalnızca GRE paketlerinin geçmesine izin verir. Sonuç olarak, pingler tünel taşıma IP'sinden uzak tünel taşıma IP'sine çalışmayacaktır.
Ping kontrolü, kaynak tünel taşıma IP'sinden hedef tünel taşıma IP'sine oluşturulan bir GRE paketi ile sonuçlanırken, GRE paketinin yükü (iç IP) kaynak ve hedef tünel IP'si olacaktır.
Ping testi başarılı olmazsa ve önceki öğeler doğrulanırsa, icmp pinginin daha sonra bir IPsec paketine kapsüllenen ve daha sonra kaynak IPsec adresinden hedef IPsec adresine gönderilen bir GRE paketi ile sonuçlandığından emin olmak için bir paket yakalama gerekebilir.. GRE tünel arabirimi ve IPsec oturum sayaçlarındaki sayaçlar da gönderme ve alma paketlerinin artıp artmadığını göstermeye yardımcı olabilir.
Ping trafiğine ek olarak, yakalama, boşta trafik sırasında bile keepalive GRE paketlerini de göstermelidir. Son olarak, BGP yapılandırılmışsa, BGP keepalive paketleri VPN üzerinden IPSEC paketlerinde kapsüllenmiş GRE paketleri olarak da gönderilmelidir.
BGP Sorun Giderme ve Doğrulama
BGP Oturumları
VPN IPsec tüneli üzerinden yönlendirme protokolü olarak BGP gereklidir. Yerel BGP komşusu, Özel Bulut Sunucusu BGP komşusu ile bir eBGP oturumu oluşturmalıdır. EBGP komşu IP adresleri, yerel ve uzak tünel IP adresleri ile aynıdır. Önce BGP oturumunun hazır olduğundan emin olun ve ardından Adanmış Bulut Sunucusundan doğru yolların alındığını ve Adanmış Bulut Sunucusuna doğru varsayılan yolun gönderildiğini doğrulayın.
GRE tüneli açıksa, yerel ve uzak GRE tüneli IP'si arasında bir ping'in başarılı olduğunu doğrulayın. Ping başarılıysa ancak BGP oturumu gelmiyorsa, BGP oluşturma hataları için BGP günlüğünü araştırın.
Daha yaygın BGP müzakere sorunlarından bazıları şunlardır:
-
Uzak AS numarası, Özel Bulut Sunucu tarafında yapılandırılan AS numarasıyla eşleşmiyor, komşu AS yapılandırmasını tekrar kontrol edin.
-
Yerel AS numarası, Ayrılmış Bulut Sunucusu tarafının beklediği ile eşleşmiyor, yerel AS numarasının beklenen Adanmış Bulut Sunucu parametreleriyle eşleştiğini doğrulayın.
-
Bir güvenlik duvarı, GRE paketlerinde kapsüllenmiş BGP TCP paketlerinin IPsec tüneline gönderilmesini veya IPSEC tünelinden alınmasını engelliyor
-
Uzak BGP komşu IP, uzak GRE tüneli IP'si ile eşleşmiyor.
BGP Rota Değişimi
Her iki tünel için de BGP oturumu doğrulandıktan sonra, Adanmış Bulut Sunucu tarafından doğru yolların gönderilip alındığından emin olun.
Özel Bulut Sunucusu VPN çözümü, müşteri/iş ortağı tarafından iki tünel kurulmasını beklemektedir. İlk tünel Adanmış Bulut Sunucusu veri merkezi A'ya, ikinci tünel ise Özel Bulut Sunucusu veri merkezini B'ye işaret eder. Her iki tünel de aktif durumda olmalıdır ve çözüm aktif/aktif bir dağıtım gerektirir. Her Adanmış Bulut Sunucusu veri merkezi, yerel /25 rotasının yanı sıra /24 yedekleme rotasının reklamını yapar. Adanmış Bulut Sunucusundan gelen BGP yollarını kontrol ederken, Adanmış Bulut Sunucusu veri merkezi A'ya işaret eden tünelle ilişkili BGP oturumunun Tahsis Edilmiş Bulut Sunucusu veri merkezi A /25 yerel yolunu ve /24 yedekleme yolunu aldığından emin olun. Ayrıca, Özel Bulut Sunucusu veri merkezi B'ye işaret eden tünelin Özel Bulut Sunucusu veri merkezi B/25 yerel yolunu ve /24 yedekleme yolunu aldığından emin olun. /24 yedekleme yolunun, Adanmış Bulut Sunucu veri merkezi A ve Adanmış Bulut Sunucu veri merkezi B'de ilan edilen rota ile aynı olacağını unutmayın.
Bu veri merkezine giden tünel arabirimi çöktüğünde, Adanmış Bulut Sunucusu veri merkezine yedeklilik sağlanır. Adanmış Bulut Sunucusu veri merkezi A'ya bağlantı kesilirse, trafik Adanmış Bulut Sunucu veri merkezi B'den veri merkezi A'ya iletilir. Bu senaryoda, veri merkezi B'ye giden tünel, veri merkezi B'ye trafik göndermek için veri merkezi B/25 yolunu kullanacak ve veri merkezi B'ye giden tünel, veri merkezi B aracılığıyla A veri merkezine trafik göndermek için yedekleme/24 yolunu kullanacaktır.
Her iki tünel de aktif olduğunda, veri merkezi A tünelinin veri merkezi B veri merkezine trafik göndermek için kullanılmaması ve bunun tersi olması önemlidir. Bu senaryoda, veri merkezi B hedefi olan A veri merkezine trafik gönderilirse, veri merkezi A trafiği veri merkezi B'ye iletir ve ardından veri merkezi B veri merkezi B tüneli aracılığıyla trafiği kaynağa geri göndermeye çalışır. Bu, optimal olmayan yönlendirmeye neden olur ve ayrıca güvenlik duvarlarını geçen trafiği bozabilir. Bu nedenle, normal çalışma sırasında her iki tünelin de aktif/aktif bir konfigürasyonda olması önemlidir.
0.0.0.0/0 rotasının müşteri tarafından Adanmış Bulut Sunucusu veri merkezi tarafına ilan edilmesi gerekir. Daha spesifik rotalar Özel Bulut Sunucu taraf ı tarafından kabul edilmeyecektir. 0.0.0.0/0 yolunun hem Özel Bulut Sunucusu veri merkezi A tüneli hem de Özel Bulut Sunucusu veri merkezi B tünelinden duyurulduğundan emin olun.
MTU Yapılandırması
Özel Örnek tarafında, büyük paket boyutları için MTU'yu dinamik olarak ayarlamak için iki özellik etkinleştirilmiştir. GRE tüneli, VPN oturumu boyunca akan IP paketlerine daha fazla başlık ekler. IPsec tüneli, GRE başlıklarının üzerine ek başlıkları ekler, tünel üzerinde izin verilen en büyük MTU'yu daha da azaltacaktır.
GRE tüneli MSS özelliğini ayarlar ve MTU keşif özelliğindeki GRE tünel yolu, Özel Örnek tarafında etkinleştirilir. VPN tüneli üzerinden trafiğin MTU'sunun dinamik olarak ayarlanmasına yardımcı olmak için müşteri tarafında “ip tcp ajust-mss 1350" veya eşdeğer komutu ile “tunnel path\ u0002mtu-discovery” veya eşdeğer komutu yapılandırın.