Virtual Connect, yönlendirme ve GRE kontrolünün bir cihaz tarafından sağlanmıştır ve IPSec kontrol aracı başka bir kişi tarafından sağlanmıştır çift katmanlu uç mimarisi kullanır.

Sanal Bağlantı bağlantısı tamamlandıktan sonra, Müşterinin kurumsal ağı ve Adanmış Örnek Cisco'nun veri merkezleri arasında iki GRE IPSec tüneli oluşturulacak. İlgili Bölge içindeki her yedekli veri merkezinden. Eşleme için gereken ek ağ öğeleri, İş Ortağı veya Müşteri tarafından Control Hub Sanal Bağlantı etkinleştirme formu aracılığıyla Cisco'ya exchange'tir.

Aşağıdaki şekil, müşteri tarafındaki 2-konsantratör seçeneği için sanal bağlantı dağıtım modelinin örneğini göstermektedir.

Sanal Bağlantı - VPN, Müşterinin Hub Sitelerinin belirli bir bölge içindeki Adanmış Örneğin veri merkezlerinin DC1 ve DC2'ye bağlı olduğu bir Hub tasarımıdır.

Daha iyi yedeklilik için iki Hub sitesi önerilir ancak iki tünele sahip One Hub sitesi de desteklenen bir dağıtım modelidir.

Ortakların, Müşterilerle yakın bir şekilde çalışarak Sanal Bağlantı hizmet bölgesi için en uygun yolun seçilmesini sağlamaları beklenmektedir.

Aşağıdaki şekil, Ayrılmış Örnek bulut bağlantısı eşleme bölgelerini göstermektedir.

Sanal Bağlantı eklentisi için yönlendirme, Özel Örnek ve Müşteri Şirket Donanımı (CPE) arasında harici BGP (eBGP) kullanılarak uygulanır. Cisco, ilgili ağın bir bölge içindeki her yedek DC için Müşterinin CPE'sinde tanıtacak ve Cisco'ya varsayılan bir rotanın tanıtımı için CPE gereklidir.

• Cisco bakım ve atamaları

  • Tünel Arayüzü IP adresi (yönlendirme için geçici bağlantı) Cisco, belirtilen bir Paylaşılan Adres Alanından (genel olmayan yönlendirilebilir) atar

  • Tünel taşıma desiyasyonu adresi (Cisco tarafı)

  • Müşteri BGP yönlendirme yapılandırması için özel otonom sistem numaraları (ASN'ler)

    • Cisco, belirtilen özel kullanım aralığından atar: 64512 - 65534

• Adanmış Örnek ve CPE arasında yönlendirme değişimi için kullanılan eBGP

  • Cisco, atanan /24 ağı ilgili bölgedeki her DC için 2/25 ağına bölecek

  • Sanal Bağlantı'da her /25 ağın, ilgili noktadan noktaya VPN tünelleri (geçici bağlantı) üzerinden Cisco tarafından CPE'ye geri tanıtıldı

  • CPE, uygun eBGP komşuları ile yapılandır olmalı. Bir CPE kullanılırsa iki eBGP komşusu kullanılacaktır, bir de her uzak tüneli işaret eden. İki CPE kullanıyorsanız her CPE'de CPE için tek uzak tünelde bir eBGP komşusu olacak.

  • Her GRE tünelin Cisco tarafı (tünel arayüzü IP), CPE'de BGP komşusu olarak yapılandırılmıştır

  • Her bir tünel üzerinde varsayılan bir yönlendirmenin tanıtımını yapmak için CPE gereklidir

  • CPE, gerektiğinde cutomer'ın kurumsal ağında öğrenilen rotaları yeniden dağıtılabilir.

• Başarısız olmayan bağlantı hatası koşulu altında, tek bir CPE'de iki etkin/etkin tünel olur. İki CPE düğümü için her CPE'de bir etkin tünel olacak ve her iki CPE düğümünün de etkin olması ve trafiğin aktarılacak olması gerekir. Başarısız olmayan senaryo altında, trafik doğru /25 hedeflere giden iki tünelde ayrılmalı; eğer tünelden biri arızalıysa kalan tünel her ikisi için de trafiği taşıyabilir. Böyle bir hata senaryoda, /25 ağı arızalı olduğunda, /24 ağı yedek yol olarak kullanılır. Cisco, bağlantının kaybedil olduğu DC'ye doğru dahili WAN üzerinden müşteri trafiğini gönderecek.

IPsec tünel müzakeresi iki aşamadan oluşur: IKEv2 aşaması ve IPsec aşaması. IKEv2 faz müzakeresi tamamlanmazsa, ikinci bir IPsec fazının başlatılması söz konusu olmaz. Öncelikle Cisco ekipmanlarında "show crypto ikev2 sa" komutunu veya üçüncü taraf ekipmanlarda benzer bir komutu çalıştırarak IKEv2 oturumunun aktif olup olmadığını doğrulayın. IKEv2 oturumu etkin değilse, olası nedenler şunlar olabilir:

• İlgi çekici trafik IPsec tünelini tetiklemiyor.

• IPsec tünel erişim listesi yanlış yapılandırılmış.

• Müşteri ile Özel Örnek IPsec tünel uç noktası IP'si arasında bağlantı yoktur.

• IKEv2 oturum parametreleri, Özel Örnek tarafı ile müşteri tarafı arasında eşleşmiyor.

• Bir güvenlik duvarı IKEv2 UDP paketlerini engelliyor.

Öncelikle, IKEv2 tünel müzakeresinin ilerleyişini gösteren herhangi bir mesaj olup olmadığını görmek için IPsec günlüklerini kontrol edin. Günlükler, IKEv2 müzakeresinde bir sorun olduğunu gösterebilir. Günlük mesajlarının eksikliği, IKEv2 oturumunun etkinleştirilmediğini de gösterebilir.

IKEv2 müzakeresinde sık karşılaşılan bazı hatalar şunlardır:

• CPE tarafındaki IKEv2 ayarları Cisco tarafıyla uyuşmuyor, belirtilen ayarları tekrar kontrol edin:

  • IKE sürümünün 2 olduğunu kontrol edin.

  • Şifreleme ve Kimlik Doğrulama parametrelerinin Ayrılmış Örnek tarafında beklenen şifrelemeyle eşleştiğini doğrulayın.

    "GCM" şifresi kullanıldığında, GCM protokolü kimlik doğrulamayı yönetir ve kimlik doğrulama parametresini NULL olarak ayarlar.

  • Ömür boyu ayarını doğrulayın.

  • Diffie Hellman modül grubunu doğrulayın.

  • Sahte Rastgele İşlev ayarlarını doğrulayın.

• Kripto haritasına erişim listesi şu şekilde ayarlanmadı:

  • GRE'ye izin ver (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 mesajları IKEv2 aşaması için herhangi bir müzakere etkinliği göstermiyorsa, o zaman bir paket yakalama gerekebilir.

Doğru şekilde yapılandırıldığında, IPsec tüneli ve birinci aşama IKEv2 müzakeresi aşağıdaki şekilde başlar:

• GRE, CPE tarafı GRE tünel arayüzünden Özel Örnek tarafı GRE tünel arayüzüne kadar canlı tutulur.

• BGP komşu TCP oturumu, CPE tarafındaki BGP komşusundan Dedicated Instance tarafındaki BGP komşusuna.

• CPE yan tünel IP adresinden Özel Örnek yan tünel IP adresine ping atın.

  Ping tünel taşıma IP'sinden tünel taşıma IP'sine olamaz, tünel IP'sinden tünel IP'sine olmalıdır.

IKEv2 trafiği için bir paket izleme gerekiyorsa, UDP için filtreyi ayarlayın ve 500 numaralı portu (IPsec uç noktalarının ortasında bir NAT aygıtı olmadığında) veya 4500 numaralı portu (IPsec uç noktalarının ortasına bir NAT aygıtı yerleştirildiğinde) kullanın.

500 veya 4500 portuna sahip IKEv2 UDP paketlerinin DI IPsec IP adresine gönderilip alındığını doğrulayın.

IPsec ikinci aşamasını gidermeden önce IPsec birinci aşamasının (yani IKEv2 güvenlik ilişkisinin) etkin olduğunu doğrulayın. IKEv2 oturumunu doğrulamak için "show crypto ikev2 sa" veya eşdeğer bir komut çalıştırın. Çıktıda, IKEv2 oturumunun birkaç saniyeden uzun süredir açık olduğunu ve sekmediğini doğrulayın. Oturum çalışma süresi çıkışta oturumun "Etkin Süresi" veya eşdeğeri olarak gösterilir.

IKEv2 oturumunun aktif ve çalışır durumda olduğu doğrulandıktan sonra IPsec oturumunu araştırın. IKEv2 oturumunda olduğu gibi, IPsec oturumunu doğrulamak için "show crypto ipsec sa" veya eşdeğer bir komut çalıştırın. GRE tüneli kurulmadan önce hem IKEv2 oturumu hem de IPsec oturumu etkin olmalıdır. IPsec oturumu etkin olarak görünmüyorsa, hata mesajları veya müzakere hataları için IPsec günlüklerini kontrol edin.

IPsec görüşmeleri sırasında karşılaşılabilecek daha yaygın sorunlardan bazıları şunlardır:

CPE tarafındaki ayarlar Dedicated Instance tarafındaki ayarlarla uyuşmuyor, ayarları tekrar kontrol edin:

• Şifreleme ve Kimlik Doğrulama parametrelerinin Ayrılmış Örnek tarafındaki ayarlarla eşleştiğini doğrulayın.

• Mükemmel İletme Gizliliği ayarlarını ve Ayrılmış Örnek 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.

IPsec ve IKEv2 oturumları çalışır ve etkin olarak doğrulandığında, GRE tüneli canlı tutma paketleri, Özel Örnek ile CPE tüneli uç noktaları arasında akabilir. Tünel arayüzü durum göstermiyorsa, bazı yaygın sorunlar şunlardır:

• Tünel arayüzü taşıma VRF'si, loopback arayüzünün VRF'siyle eşleşmiyor (tünel arayüzünde VRF yapılandırması kullanılıyorsa).

  Tünel arayüzünde VRF konfigürasyonu kullanılmıyorsa bu kontrol göz ardı edilebilir.

• CPE yan tünel arayüzünde canlı tutmalar etkinleştirilmemiştir

  CPE ekipmanında keepalive'lar desteklenmiyorsa, Cisco'ya bildirimde bulunulmalı ve böylece Ayrılmış Örnek tarafındaki varsayılan keepalive'lar da devre dışı bırakılmalıdır.

  Keepalive'lar destekleniyorsa, keepalive'ların etkin olduğunu doğrulayın.

• Tünel arayüzünün maskesi veya IP adresi doğru değil ve Ayrılmış Örnek'in beklenen değerleriyle eşleşmiyor.

• Kaynak veya hedef tünel taşıma adresi doğru değil ve Ayrılmış Örnek'in 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ıyor)

Bir ping testi, yerel tünel arayüzünün çalışır durumda olduğunu ve uzak tünel arayüzüne bağlantının iyi olduğunu doğrulamalıdır. Ping kontrolünü tünel IP'sinden (taşıma IP'sinden değil) uzak tünel IP'sine doğru gerçekleştirin.

Ping kontrolü, kaynak tünel taşıma IP'sinden hedef tünel taşıma IP'sine bir GRE paketi oluşturulmasıyla 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 maddeler doğrulanırsa, icmp ping'inin bir GRE paketiyle sonuçlandığından ve ardından bir IPsec paketine kapsüllendiğinden ve ardından kaynak IPsec adresinden hedef IPsec adresine gönderildiğinden emin olmak için bir paket yakalama gerekebilir. GRE tünel arayüzündeki sayaçlar ve IPsec oturum sayaçları da gönderilen ve alınan paketlerin artıp artmadığını göstermeye yardımcı olabilir.

Ping trafiğine ek olarak, yakalamanın boşta trafik sırasında bile keepalive GRE paketlerini de göstermesi gerekir. Son olarak, eğer BGP yapılandırılmışsa, BGP keepalive paketleri, IPSEC paketleri içerisinde kapsüllenmiş GRE paketleri olarak da VPN üzerinden gönderilmelidir.

Adanmış Örnek tarafında, büyük paket boyutları için MTU'yu dinamik olarak ayarlamak üzere iki özellik etkinleştirilmiştir. GRE tüneli, VPN oturumu üzerinden akan IP paketlerine daha fazla başlık ekler. IPsec tüneli, GRE başlıklarının üstüne ek başlıklar ekleyerek tünel üzerinden 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. "ip tcp adjust-mss 1350" veya eşdeğer komutu ve "tunnel" komutunu yapılandırın path\u0002mtu-discovery" veya VPN tüneli üzerinden geçen trafiğin MTU'sunun dinamik olarak ayarlanmasına yardımcı olmak için müşteri tarafında eşdeğer bir komut.