Split tünel, genel bir ana makineyi ASA'nın NAT kurallarından muaf tutmaz
Bir split-include rotası genel ana makineyi tünele çeker; orada ASA'nın hairpin yapması ve kaynağı çevirmesi gerekir. İki adımdan birini atlarsanız akış düşer.
Split tünel genellikle kurumsal trafiği tünelin içinde, internetin geri kalanını güvenlik duvarının dışında tutmanın bir yolu olarak tanımlanır. Bu tanımın iki yarısı da aynı şekilde yanlıştır. Split tünel, istemcinin verdiği bir rota kararıdır ve rota kararı, paketin headend'e ulaştıktan sonra ne olacağı hakkında hiçbir şey söylemez.
Genel bir adres üzerindeki, genel merkezinizin adresini görmekte ısrar eden tek bir iş ortağı hizmeti bu hikâyeyi yıkmaya yeter.
Efsane: split tünel güvenlik duvarını yoldan çıkarır
İnanış, özel aralıkların dışındaki her hedefin yerel internet bağlantısında kaldığı, böylece güvenlik duvarının onu hiç görmediği ve ona hiçbir zaman kural gerekmediğidir. Bu yalnızca hedef tünel listesinde olmadığı sürece geçerlidir. Bir operatör genel ana makineyi split-include ACL'sine eklediği anda istemci bu trafiği tünele gönderir ve ASA bunu diğer şifresi çözülmüş akışlar gibi yönlendirmek, filtrelemek ve çevirmek zorundadır. İstemcide hedef listesinden başka hiçbir şey değişmemiştir.
İstemci yönlendirici olmadı. Ona verdiğiniz politikayı izledi.
Bir split-include rotası gerçekte ne yapar
Bir Cisco ASA uzaktan erişim kurulumunda grup politikası split-tunnel-policy tunnelspecified ve standart bir ACL adlandıran split-tunnel-network-list taşır. O ACL'deki her permit satırı istemcinin tünele göndermesi gereken bir hedeftir ve diğer her şey yerel varsayılan rotayı kullanmaya devam eder.
Bir ana makine eklemek tek satırdır ve istemcinin görebildiği değişikliğin tek parçası budur: access-list RA-SPLIT standard permit host 203.0.113.20.
Ardından istemciyi yeniden bağlayın. Politika bağlantı sırasında değiş tokuş edilir, bu yüzden kurulmuş bir oturum eski listeyi korur ve değişiklik hiçbir şey yapmamış gibi görünür.
Paket aynı arayüzden girer ve çıkar
Şimdi şifre çözümünden sonraki akışı izleyin. Paket VPN tüneli üzerinden dış arayüze girdi, hedefi genel bir adres ve yönlendirme tablosu onu aynı dış arayüzden internete doğru geri gönderiyor. Tek bir arayüzden girip çıkan trafik, ASA'ya izin verilmedikçe düşürülür ve same-security-traffic permit intra-interface tam olarak bunu yapar. Bu olmadan bağlantı, yönlendirme sorunu gibi görünen ama olmayan bir şekilde başarısız olur.
Bu ayar küreseldir. İhtiyaç duyan her akış için hairpinning'e izin verir, yalnızca bu iş ortağı ana makinesi için değil, bu yüzden hızlı bir teste değil, gözden geçirilmiş bir değişikliğe aittir.
Hedefle sınırlı PAT neden isteğe bağlı değildir
Şifresi çözülmüş paketteki kaynak adresi hâlâ istemcinin VPN adresidir, genellikle 10.77.0.0/24 gibi bir havuzdan. O adresin genel internette rotası yoktur, bu yüzden iş ortağı ya hiç yanıt vermez ya da hiçbir yere yanıt verir.
Çeviri kaynağı düzeltir ve hedefi dokunulmadan bırakır. Nesneler başka bir yerde zaten tanımlı olduğundan, bu hedefle sınırlı manuel bir kural şu biçimdedir:
same-security-traffic permit intra-interface
object network RA_POOL
subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
host 203.0.113.20
nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOSTdestination static kısmı önemlidir. Onu atlarsanız kural, amaçlanandan çok daha fazla trafikle eşleşebilecek geniş bir çeviriye dönüşür ve sıralamada daha önce gelen geniş bir identity kuralı bunu tamamen yenebilir. Kendi kuralınızın eşleşen olduğunu varsaymadan önce show nat detail ve bölümlerin sırasını kontrol edin.
Arayüz PAT'si ayrıca iş ortağının ASA'nın arayüz adresini gördüğü anlamına gelir; bu adres yukarı akışta yeniden çevrilebilir. Sözleşme bir adres adlandırıyorsa, tek bir atlama yerine uçtan uca doğrulayın.
Doğru test hedefiyle kanıtlayın
Genel bir what-is-my-ip sayfası değil, iş ortağı ana makinesinin kendisini kullanın. O sayfa neredeyse kesinlikle split listesinin dışındadır, bu yüzden yerel internet adresinizi bildirir ve bu yol hakkında hiçbir şey söylemez. İş ortağı hizmetine yeni bir bağlantı açın ve hangi kaynağı gözlemlediklerini sorun ya da packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed çalıştırıp NAT ve yönlendirme aşamalarını satır satır okuyun. İstemciden yapılan traceroute daha zayıf bir kontroldür, çünkü zaten gerçekleşmiş yolu gösterir, onu seçen politikayı değil.
Ardından neyin değişmemesi gerektiğini kontrol edin. Sıradan bir web sitesi hâlâ yerel bağlantıdan çıkmalı ve tünel listesindeki özel bir kaynak hâlâ erişilebilir olmalıdır. İş ortağını düzeltip bu ikisinden birini bozan değişiklik başka bir hatadır.
Bu tasarımın çalışan sürümü kısadır: split ACL'de bir ana makine, hairpin izni, hedefle sınırlı bir PAT kuralı. Hikâyedeki geri kalan her şey efsanedir.