VPN trafiği için ASA identity NAT ve IOS NAT istisnası

Cisco ağ geçitlerinde hem ASA identity NAT hem de IOS NAT sınıflandırıcı istisnası VPN adreslerini korur. Kurallar, çevirinin nerede atlandığı noktasında farklıdır.

Bir şube, internet PAT'i ve site-to-site VPN'i aynı Cisco ağ geçidinde çalıştırır ve NAT eklendiği anda VPN çalışmayı durdurur. Tünel içindeki adresler artık crypto ACL'in koruduğu adreslerle eşleşmez ya da karşı taraf, rotası olmayan çevrilmiş adresler görür. Cisco bunu iki yerde çözer: ASA, adresi kendisine eşleyen bir NAT kuralı seçer; IOS ise ACL içindeki deny ile akışı çeviri kuralının dışında tutar. İkisi de özgün adresleri korur ve hiçbiri NAT işlemesini atlatmaz.

Kural seçmeden önce akışı kaydedin

Korumayı beklediğiniz akışı yazarak başlayın: yerel LAN kaynağı, uzak hedef ve IPsec ilkesinin koruduğu tam adres çifti. Bunu kuralı düzenlemeden önce yapın, çünkü bu küme hangi sınıflandırıcının veya NAT kuralının eşleşmesi gerektiğini gösterir.

Ardından amaçladığınız kuralı değil, gerçekten eşleşen kuralı bulun. Her iki platformda NAT belirli bir sırayla değerlendirilir ve istisnanız incelenmeden önce daha erken bir kural kazanabilir. Doğru görünen ama başka bir kurala yenilen bir istisna, beklenen paketi koruma ilkesine asla teslim etmez. Belirti, istisnanın hiç olmamasıyla aynıdır; bu yüzden yapılandırma değiştirilmeden önce kural sırası okunmalıdır.

ASA identity NAT bir kuraldır, atlatma değil

ASA'da identity NAT, çevrilmiş adresi özgün adrese eşit olan bir NAT kuralıdır. Herhangi bir kural gibi seçilir ve yine de bir çeviri girdisi kurar, yani paket NAT işlemesini atlamaz. Değişen şey, ağdaki adreslerin aynı kalmasıdır ve IPsec ilkesinin ihtiyacı budur.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Kuralın arayüzleri ve route-lookup ayarı iletim tasarımıyla uyuşmalıdır. Adresi doğru eşleyen ancak yanlış arayüz çiftine uygulanan kural, akışınız için seçilmez. Route-lookup, çevrilmiş paketin yönlendirilip yönlendirilmeyeceğine ya da özgün hedefin kullanılıp kullanılmayacağına karar verir ve bu, dönüş trafiğinin tünelden geri gelip gelmeyeceğini belirler.

ASA'nın kendisine yönetim erişimi ayrı bir durumdur. Yönetim trafiği için identity NAT kullanıyorsanız sürüme özgü route-lookup koşulu geçerlidir ve bir VPN örneğinden kopyalanan geniş bir istisna SSH'yi düzeltmez.

IOS NAT ACL'de deny, burada seçilmedi anlamına gelir

IOS'ta internet NAT bir kaynak listesiyle yürütülür ve bu ACL bir sınıflandırıcıdır, filtre değil. Permit satırı trafiği çeviri için seçer; deny satırı paketin burada seçilmediği anlamına gelir. Bu deny, arayüz ACL'indeki deny gibi paketi düşürme talimatı değildir.

Burada seçilmedi, hiçbir yerde çevrilmedi ifadesinden de dardır. Başka bir NAT kuralı, başka bir arayüz veya route-map akışı hâlâ çevirebilir, bu yüzden tüm NAT tablosu okunmalıdır. Paketin yine de bir rotaya, eşleşen crypto ACL'e ve gerçek erişim denetimi sınırlarında izne ihtiyacı vardır.

Minimal bir IOS düzeni deny'ı aynı listede permit'in üstüne koyar ve overload kuralını o listeye yönlendirir. O zaman crypto ACL, deny'ın çeviriden çıkardığı çiftin aynısını korur.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

İki model için tek test edilebilir soru

İki model de aynı soruyu yanıtlar: bu akışa hangi kural eşleşti ve hangi adresler arayüzden çıktı? Dış arayüzde yakalayın ve kaynak adresi ağ geçidinden önce ve sonra karşılaştırın. Ardından karşı tarafın tünele bakışını denetleyin, çünkü SA ayakta olabilir ve korunan akış başka yerde çevriliyor olabilir.

ASA'da nat detail ve çeviri tablosunu gösterin; IOS'ta ip nat translations ve ilgili ACL sayaçlarını gösterin. Hiç artmayan bir kural hiç seçilmemiştir ve bu, crypto yapılandırmasına değil sıraya, arayüze ya da yöne işaret eder.

Yapılandırma genellikle nerede bozulur

Yaygın arızalar mekaniktir. Deny, permit'in altındadır ve asla eşleşmez. Sınıflandırıcı yanlış yönde uygulanır, bu yüzden dönüş akışı çevrilir. Identity kuralı doğru adresleri ama yanlış arayüz çiftini kapsar. Crypto ACL, NAT kuralının sunduğuyla artık eşleşmeyen bir alt ağı korur.

Özgün ve sunulan adres çiftini kural sahibinin yanına kaydedin; böylece sonraki mühendis sınıflandırıcının neden çeviriyi reddettiğini ama güvenlik duvarının uygulamaya izin verdiğini görür. Bunu kişisel notta değil, değişiklik kaydında tutun. Ardından her NAT değişikliğinden sonra akışı yeniden çalıştırın, çünkü kural metni değişmese bile kural sırası yapılandırmanın parçasıdır. Ayakta kalkan bir tünel adreslerin hayatta kaldığının kanıtı değildir; yalnızca yakalanan paket ve karşı tarafın kapsülü açtıktan sonraki görünümü kanıttır.

İlgili makaleler