VPN trafiği çözdükten sonra hangi ASA kuralı onu görür

İlk vazgeçilmesi gereken varsayım, kripto ACL'nin bir erişim ilkesi olduğudur. Değildir. Bir Cisco ASA'da bu liste tek bir dar soruyu yanıtlar: hangi paketler korunmayı hak eder, ve bu yanıt çözülen paketin güvenlik duvarının arkasındaki sunucuya erişip erişemeyeceği hakkında hiçbir şey söylemez. Erişime daha sonra karar verilir: bir arayüz ilkesiyle, bir grup ilkesi filtresiyle ya da ikisiyle birden, tünelin nasıl kurulduğuna bağlı olarak.

Kripto ACL farklı bir soruyu yanıtlar

Kripto ACL bir eşleşme listesidir. Tünele iki taraf arasında neyin şifreleneceğini söyler; onunla eşleşmeyen paket korunmaz. Onu genişletmek korumanın kapsamını değiştirir, başka bir şeyi değil.

Bu yüzden oraya bir alt ağ eklemek tüneli ayağa kaldırabilir ama gerçek uygulama yine de başarısız olur. Tünel ayakta çünkü artık bir eşleşme var. Uygulama başarısız çünkü o listede hiçbir şey hiçbir şeye izin vermiyor. İki farklı soru, iki farklı liste.

Atlama ayarının gerçekte neyi atladığı

sysopt connection permit-vpn korunan trafiğin, gelen tarafta aksi halde geçerli olacak arayüz ACL denetimini atlamasına izin verir. VPN dağıtımları için bir kolaylıktır ve geneldir. Grup ilkesine dokunmaz ve kullanıcı başına yetkilendirme filtresine de dokunmaz.

Varsayım yerine gerçek değeri okuyun: show running-config all sysopt ayarı hiç açıkça yapılandırılmamış olsa bile yazdırır, ve birçok karışıklık tam orada başlar.

Ayar genel olduğu için, onu başarısız tek bir alt ağda hızlı bir deney olarak sınamak kötü bir takastır. O güvenlik duvarındaki diğer her tünel sonucu paylaşır. Ayarı geri alma planı olan bilinçli bir değişikliğe saklayın.

Filtreyi çözme yönünde okuyun

Bir LAN-to-LAN vpn-filter arayüzün değil, tünelin bakış açısıyla yazılır. Çözme sonrası paket böyle göründüğü için uzak ağ kaynak konumuna, yerel ağ ise hedef konumuna gelir. Aynı filtre daha sonra şifrelemeden önce ters yönde yeniden değerlendirilir, adres roller tersine döner.

Port koşulları, kopyalanmış bir arayüz ACL'sinden daha fazla özen hak eder, tam da bu nedenle. Bir hedef portuna izin veren kural, yeni bir bağlantının o portu kaynak olarak kullandığı ters yönde istenmeyen bir etki yapabilir. Listeyi kurmadan önce hangi tarafın başlatabileceğini, gerçek hizmeti ve kapalı kalması gereken karşı tarafı yazın.

Hangi filtrenin gerçekten eklendiğini doğrulayın: show running-config group-policy ve show vpn-sessiondb detail l2l birlikte oturumun neyi devraldığını söyler. Hiçbir ilkenin başvurmadığı bir ACL'yi düzenlemek hiçbir şeyi değiştirmez.

Bir ACL nesnesini iki iş için yeniden kullanmayın

Arayüz access-group ile vpn-filter aynı tür nesne gibi görünür ve farklı noktalarda farklı adres yönelimiyle değerlendirilir. Tek bir listeyi ikisine de atamak, tüneli düzeltip fiziksel arayüzü sessizce gevşeten bir değişikliğe davetiye çıkarır.

Onları ayrı tutun, işlerine göre adlandırın ve yön farkının adlarda görünmesini sağlayın.

Yeni bağlantılarla, iki yönde de doğrulayın

Planlı bir değişiklikten sonra, izin verilmesi gereken bir yeni bağlantı ve reddedilmesi gereken bir yeni bağlantı açın, ardından adresleri, yönü ve ilke eşleşmesini sonuçla birlikte kaydedin. Kurulmuş bir oturum yeni bağlantı filtrelemesi hakkında hiçbir şey kanıtlamaz, çünkü eski kurallar altında zaten kabul edilmiştir.

Denetimi de hesaba katın. Üretici belgeleri, bir VPN filtresinin bir denetim motorunun açtığı her ikincil bağlantıyı değil ilk bağlantıyı denetlediğini belirtir, bu nedenle bir denetim kanalı ve ona bağlı medya akışı farklı muamele görebilir. Uygulama protokolü tanıyorsa, tek bir port sondası yerine gerçek akışı test edin.

Geniş bir atlamadan sonra kullanılabilir hale gelen tünel, kısıtlamanın kaldırıldığını söyler, karşılandığını değil. Saklamaya değer sonuç, bir sonraki gözden geçirmede işaret edebileceğiniz adlandırılmış bir uygulama noktasıdır.