ASA packet-tracer ile VPN akışı nasıl modellenir

ASA üzerindeki packet-tracer dar bir soruyu yanıtlar: bu paket, buraya bu tuple ile girdiğinde izinli olur muydu ve nereye giderdi. Uzak ucun bir şey alıp almadığını yanıtlamaz. Yaygın hata, test etmek istediğiniz şey tünelin içinde giden uygulama iken dış bir IKE tuple vermektir. Önce tuple'ı düzeltin, fazları okuyun, sonra simülatörün göremediği her şey için gerçek kanıt toplayın.

Aşağıdaki yürüyüş, ACL, NAT kuralı ve tunnel-group bağlamının önünüzde olduğunu varsayar. Bunlar olmadan çıktı, denetleyemeyeceğiniz bir politikayı tanımlar.

Adım 1: iç akışı sade sözcüklerle yazın

Herhangi bir şey yazmadan önce uygulamayı tanımlayın. İçerideki bir ana bilgisayarın uzak ağ geçidinin arkasındaki sunucuya SSH açması, belirli bir kaynak bağlantı noktası olan tek bir iç TCP akışıdır. ACL ve VPN filtresinin değerlendirdiği akış budur, dolayısıyla yazdığınız akış da budur.

Bunu tek bir cümle olarak yazın, sonra alan alan çevirin:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Adım 2: girişi ve yönü seçin

Giriş, paketin geldiği arayüzdür, ondan çıktığı arayüz değil. Başlatan bir LAN ana bilgisayarı için bu inside arayüzüdür. Aynı oturumun dönüş paketi için bu outside arayüzüdür ve tuple tersine döner. Hedefi kaynak olarak yazmak, inandırıcı ama ilgisiz bir ALLOW kazanmanın ikinci en yaygın yoludur.

Bağlantı noktaları da yönlüdür. Hizmet bağlantı noktası başlatılan bir istekte hedef alanına, istemcinin kısa ömürlü bağlantı noktası ise kaynak alanına aittir. TCP hedefi 500 olan bir model, 500 üzerinde dinleyen bir TCP uygulamasını tanımlar; komutta sayı göründü diye IKE testine dönüşmez.

Adım 3: fazları sırayla okuyun

Çıktıdaki her faz, sahibi olan bir karardır: rota araması, ACL, NAT, ardından VPN veya tünel seçimi. Bunları basıldıkları sırayla okuyun ve tasarımla uyuşmayan ilk fazda durun.

NAT çoğu kişiyi yanıltır. Çevrilen kaynak, tünel için trafiği seçen crypto ACL'nin dışına düşerse akış izinli olabilir ve hiç kapsüllenmeyebilir. İz, çevrilen adresi basar, bu yüzden onu özgün adresle değil tünelin ilginç trafiğiyle karşılaştırın.

Adım 4: hangi atlamaları seçtiğinizi denetleyin

detailed biçimi denetimleri atlayan seçenekler alır ve Cisco, ACL, VPN filtresi, uRPF ve IPsec sahtekârlık denetimlerini kapsayan bir bypass-checks seçeneğini belgeler. Bunlar atlanarak elde edilen bir ALLOW, rotanın ve NAT'ın çalışacağını söyler, politikanın gerçek bir paketi kabul edeceğini değil. Seçenekleri sonucun yanına yazın.

Politika yanıtına ihtiyacınız varsa atlamalar olmadan çalıştırın. Bir yönlendirme sorusunu yalıtıyorsanız onlarla çalıştırın ve sonucu yönlendirme yanıtı olarak etiketleyin.

Adım 5: boşluğu gerçek alışverişle kapatın

Simüle edilmiş izin ASA'da durur. Uzak ağ geçidinin paketi çözüp çözmediği, sunucunun bağlantıyı kabul edip etmediği ve bir yanıtın geri gelip gelmediği ayrı gözlemlerdir. Uç nokta sayaçlarını kullanın veya onaylanmış bir yolda dar bir yakalama.

Bazı trace ve replay seçenekleri paket iletir veya durumu korur. Her varyantı salt okunur bir arama olarak ele almak yerine sürümünüz ve onaylanmış tanılama yordamınız için belgelenmiş davranışı izleyin.

İzin hâlâ size neyi söyleyemez

Dört şeyi tek bir notta tutun: tuple, eşleşen NAT kuralı, akışı taşıması gereken tünel veya politika ve yöne özgü gözlem. Bunlar olmadan sonraki mühendis yerel bir politika kararını yerleşik bir denetim düzleminden ve çalışan bir hizmetten ayıramaz. İlk başarısızlığı izleyen başarı da tünelin arada kalkması gerektiğinin kanıtı değildir; fazı ve durum değişikliğini kaydedin.

İç tuple ile başlayın, tasarımla çelişen ilk fazda durun ve ancak ondan sonra uç nokta kanıtına başvurun. İz bir politika kâhinidir, teslim makbuzu değil.