ASA uzak kullanıcısı alt ağa ulaşıyor ama uygulamaya neden ulaşamıyor
Yollar tünelin çalıştığını kanıtlar, kullanıcının uygulamayı açabileceğini değil. Oturumun aldığı filtreyi okuyun, sonra izin verilen ve reddedilen bir bağlantıyı test edin.
Kullanıcınız bağlanıyor, adres alıyor, uygulamanın alt ağındaki sunucuya ping atıyor ve yine de üzerindeki hizmeti açamıyor. Bu kombinasyon ASA'da normaldir, çünkü başarılı bir tünel ile kullanılabilir bir izni farklı ayarlar belirler. Bölünmüş tünel listesi hangi hedeflerin tünele gireceğini seçti; bir VPN filtresi ve hedefin kendi erişim kuralları, şifresi çözülen isteğin neye ulaşabileceğine karar verir. Yol listesini bir şey değişene kadar genişletmek yerine üç kararı sırayla ele alın.
Karıştırılması kolay üç karar
Kabul, kullanıcının tüneli kurup kuramayacağını yanıtlar: kimlik bilgileri, sertifika ve varsa ikinci faktör. Yol seçimi, istemcinin hangi hedefleri o tünele gönderdiğini yanıtlar. Yetkilendirme, şifresi çözülen isteğin hizmete ulaşıp ulaşamayacağını yanıtlar. Kullanıcının bildirdiği hatayı yalnızca üçüncüsü üretir.
Bunları ayırmanın hızlı yolu, bir değişikliğin neyi bozacağını sormaktır. Bölünmüş listeden bir yolu kaldırmak o alt ağa giden trafiği durdurur ama hiçbir şey vermez; VPN filtresine bir ACE eklemek, istemcinin tünele ne koyduğunu değiştirmeden bir hedef verir.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Oturumun gerçekte aldığı filtreyi okuyun
Geçerli olduğunu düşündüğünüz yapılandırmadan değil, canlı oturumdan başlayın. show vpn-sessiondb detail anyconnect atanan grup ilkesini ve o oturuma bağlı filtrenin adını yazdırır. Alan boşsa hiçbir filtre bir şey uygulamıyordur ve engel başka bir yerden geliyordur.
Ardından değeri barındıran ilkeyi, varsayılanlar dahil okuyun, çünkü filtre baktığınız yerde yazılı olmak yerine devralınmış olabilir:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Oturumdaki filtre adını yeni düzenlediğiniz ACL ile karşılaştırın. Kullanıcının hiç almadığı benzer adlı bir ACL o oturumun kaynak ilkesini değiştiremez ve doğru görünen bir değişikliğin etkisiz olmasının en yaygın nedeni budur.
Öncelik geri kalanı açıklar. Filtre ayarı için bir DAP kaydı kullanıcı adı niteliklerinden üstündür, kullanıcı adı nitelikleri de grup ilkesinden üstündür. Bir oturum beklemediğiniz bir filtre gösterdiğinde, gruba dokunmadan önce o kullanıcıya uyan bir DAP ilkesi arayın.
Bölünmüş liste ile filtre ayrı alanlardır
ASA 9.x'te grup ilkesi split-tunnel-network-list ve vpn-filter ayarlarını farklı olarak tutar ve 9.22 grup ilkesi kılavuzu tam bu nedenle bunları ayrı belgeler. Ağ listesi istemci için bir yönlendirme ipucudur; filtre şifresi çözülen trafiğe uygulanan bir erişim denetim listesidir.
Bu ayrım, kullanıcının bir alt ağda tek bir HTTPS hizmetine ihtiyacı olduğunda önemlidir. Alt ağı bölünmüş listeye koyun ki paketler tünele girsin, sonra filtrede yalnızca o hizmete izin verin. Yol listesini genişletmek hiçbir şeyi yetkilendirmez, daraltmak da bir uygulama mekanizması değildir.
Bir arayüz ACL'sinin yolda olup olmadığını kontrol edin
Şifresi çözülen uzak erişim trafiği dış arayüz ACL'sinden insanların varsaydığı gibi her zaman geçmez. sysopt connection permit-vpn etkin olduğu yerde ASA o trafik için belgelenmiş VPN atlamasını uygular, geçerli VPN filtreleri ise sonrasında da geçerlidir. Ayarı topoloji şemasından akıl yürütmek yerine show run all sysopt ile kontrol edin.
Her durumda hedef ana bilgisayarın kendi güvenlik duvarı ve uygulamanın yetkilendirmesi yolda kalır. TCP 443'e izin veren bir ASA kuralı uygulamanın kullanıcıyı kabul etmesini sağlamaz.
Değişikliği reddedilen bir bağlantıyla da kabul edin
Tek başına izin verilen bir test çok az şey kanıtlar, çünkü çalışan bir tünel filtre olsun olmasın aynı ilk paketi üretir. İstemciden amaçlanan hizmeti açın, sonra kapalı kalması gereken bir hedefi deneyin ve doğru nedenle başarısız olduğunu doğrulayın.
Talebi kapatırken dört gerçeği kaydedin: kabul edilen kimlik, oturumun gerçekte aldığı ilke ve filtre, bölünmüş listedeki hedefler ve kullanıcının ulaşmasına izin verilen kaynak. Bu dördü, yol listesini güvenlik duvarına dönüştürmeden trafiğin nerede denetlendiğini açıklar.
Filtre izin verdikten sonra hizmet hâlâ reddediyorsa ana bilgisayara geçin: dinleme adresi, ana bilgisayar güvenlik duvarı ve uygulamanın kendi kullanıcı eşlemesi. Tünel o noktada işini yapmıştı ve ASA'daki ek değişiklikler yalnızca risk ekler.