Tek bir WAN arayüzü hem siteler arası hem de uzak VPN'e hizmet verebilir mi?

Tek bir genel adres aynı anda bir şube tüneli ve bir dolaşan kullanıcı havuzuna hizmet verebilir. Ancak tek bir ortak kabul kuralına hizmet veremez. Şubenin eşi ile dolaşan kullanıcı farklıdır kendilerini kim olarak beyan ettikleri, bu kanıtın nasıl denetlendiği, hangi adresleri aldıkları ve hangi öneklerin onlara yanıt verebildiği bakımından. Dış adresi kimlik değil taşıma ayrıntısı olarak ele aldığınızda tasarım çok daha basit hale gelir.

Hızlı bir sağduyu testi: yönlendiriciye dokunmadan önce iki kabul kaydını da yazmayı deneyin. Tek bir eşleştirme koşulu ikisini de kapsamak zorundaysa politika zaten belirsizdir ve ilk belirti yönlendirme veya güvenlik duvarı arızası gibi görünecek, oysa gerçekte kimlik arızasıdır.

Herhangi bir yapılandırmadan önce iki kayıt

Şube kaydı kısa ve kararlıdır. Eşin adresini veya sertifika adını, önceden paylaşılan anahtarı ya da sertifikanın güven noktasını, iki taraftaki korunan alt ağları, tünel arayüzünü ve şubeye yönelen trafiği o tünele gönderen statik yolu listeler. Her alan tek bir bilinen eş ve sabit bir önek kümesiyle ilgilidir.

Dolaşan kullanıcı kaydı daha geniş ve daha kişiseldir. İstemci protokolünü ve bağlantı noktasını, bir kullanıcının veya cihazın nasıl kimlik doğruladığını, bağlanırken verilen adres havuzunu, bu havuzun erişebildiği kaynakları, bölünmüş tünel öneklerini, istemciye itilen DNS sunucularını ve varsa ikinci bir faktörü listeler. Her alan tek bir ağ geçidi hakkında değil, bilinmeyen sayıda kullanıcı hakkındaki soruya yanıt verir.

Ayrıntı düzeyindeki bu fark, iki rolün ayrılmasının tüm nedenidir. Şube profili tek bir anahtara güvenle güvenebilir çünkü anahtar tek bir konumdaki tek bir cihaza aittir. Herkes için tek bir grup anahtarına güvenen dolaşan profil, kullanıcı başına hesap verebilirliği çökertir ve bu genellikle sonradan, dağıtım sırasında değil bir olay incelemesi sırasında ortaya çıkar.

Eş eşleştirmesi ile kimlik doğrulamanın ayrıldığı yer

IOS XE'de IKEv2 profili pazarlık edilemeyen parametreleri ve eşi seçmek için kullanılan koşulları taşır. Bu, şube tarafının ve dolaşan tarafın aynı arayüzde sonlansa ve aynı kriptografik PKI'yı paylaşsa bile kendi profillerine ihtiyaç duyduğu anlamına gelir. Cisco profil, kimlik doğrulama ve eşleştirme rollerini kendi IOS XE 17 için IKEv2 yapılandırma kılavuzunda belgeler.

Şube profili genellikle dar bir kimlikle eşleşir: uzak bir adres, bir FQDN veya bir sertifika konusu. match identity remote address 198.51.100.10 255.255.255.255 gibi bir şey tek bir eşi sabitler ve her saha için saklanan anahtarla authentication remote pre-share yeterlidir. Eşleştirmeyi eş envanterinin izin verdiği kadar belirgin tutun, çünkü seçim sırasında daha yukarıda olan çakışan bir joker karakter şube trafiğini yanlış profile çekebilir.

Dolaşan profil bir adresi sabitleyemez, bu yüzden bir grupla, bir key-id ile veya bir sertifika alanıyla eşleşir ve ardından gerçek kullanıcı denetimini AAA'ya ya da profile bağlı yetkilendirme politikasına devreder. Bu ayrım önemlidir: eş kimlik doğrulaması istemcinin tünel kurmasına izin verilip verilmediğini yanıtlar, kullanıcı başına yetkilendirme ise hangi havuzu ve hangi kaynakları aldığını yanıtlar. Şube anahtarını evrensel oturum açma olarak kullanmak ikinci yanıtı çöpe atar.

Yönlendirme ve çeviri de aynı ayrımı gerektirir

Kabul ile erişilebilirlik ayrı sorunlardır. Başarılı bir IKE ve IPsec alışverişi tarafların anahtarlar üzerinde anlaştığını kanıtlar; istemcinin aldığı havuza bir yol oluşturmaz. Bu yüzden uzak erişim havuzlarının bir dönüş yoluna ihtiyacı vardır: tünel arayüzüne işaret eden statik bir yol ya da havuz özetini enjekte eden bir yönlendirme protokolü. Şube önekleri genellikle sitenin geri kalanına hizmet eden aynı yönlendirme sürecinden gelir.

Çeviri, iki rolün en sık çakıştığı yerdir. Özel adreslerini koruması gereken siteler arası trafik, bu iki önekle sınırlı bir NAT istisnasına ihtiyaç duyar, her iki yönde. Dolaşan istemciler genellikle tünel içindeki trafikleri için de istisnaya ihtiyaç duyar, ancak internete giden trafikleri ya bölünmüş tünelle tüneli atlar ya da NAT sonrasında merkezde çıkar. Tünelden gelen her şeyi istisna tutmak klasik hatadır, çünkü gerçekten ihtiyaç duyan trafikten de çeviriyi alır.

İstisna kurallarını kabul kuralları kadar dar tutun. Bir havuz özeti ile bir şube öneki çakışırsa, tek bir paket düşürülmeden çok önce dönüş yolu belirsizleşir ve belirti temiz bir tünel arızası olarak değil, bir sitenin ara sıra bir alt ağ kaybetmesi olarak görünür.

Kesişen politikayı açığa çıkaran kabul durumları

Dört durum kurun ve sırayla çalıştırın. Şubedeki bir ana makine yalnızca şubeye ait bir kaynağa ulaşır. Dolaşan bir istemci aynı kaynağa havuz adresi üzerinden ulaşır. Dolaşan bir istemci dokunmaması gereken bir şube önekini dener. Şubenin eşi uzak erişim havuzundan bir adres almaya çalışır. Son iki durum paylaşılan bir profili yakalar, çünkü normal izlemede sessizce başarısız olurlar.

Ardından yapılandırmayı değil veri düzlemini doğrulayın. show crypto ikev2 sa ve show crypto ipsec sa her akışı hangi profilin ve hangi seçicilerin taşıdığını söylerken, show ip nat translations ve tünel sayaçları dönüş yolu ile istisnanın gerçekten eşleşip eşleşmediğini gösterir. Tünel arayüzünde bir tracer veya paket yakalama döngüyü kapatır.

Gözlenen kimliği, havuz adresini ve seçilen politikayı her sonucun yanına yazın. Her durum tam olarak bir kayda karşılık geldiğinde ve hiçbir durum geçmek için geçici bir istisnaya ihtiyaç duymadığında koşu tamamlanır.