NAT الهوية في ASA مقابل استثناء NAT في IOS لحركة VPN

يحتفظ فرع بـ PAT للإنترنت وVPN من موقع إلى موقع على البوابة نفسها من Cisco، ويتوقف VPN عن العمل بمجرد إضافة NAT. لم تعد العناوين داخل النفق تطابق ما تحميه قائمة ACL للتشفير، أو يرى الطرف المقابل عناوين مترجمة لا يملك مسارًا إليها. يحل Cisco هذا في مكانين مختلفين: تختار ASA قاعدة NAT تربط العنوان بنفسه، بينما يبقي IOS التدفق خارج قاعدة ترجمة عبر رفض في ACL. كلاهما يحافظ على العناوين الأصلية، وليس أي منهما تجاوزًا لمعالجة NAT.

سجّل التدفق قبل اختيار القاعدة

ابدأ بكتابة التدفق الذي تتوقع حمايته: مصدر الشبكة المحلية، والوجهة البعيدة، وزوج العناوين الدقيق الذي تحميه سياسة IPsec. افعل ذلك قبل تعديل أي قاعدة، لأن هذه المجموعة تخبرك أي مصنّف أو قاعدة NAT كان يجب أن تطابق.

ثم اعثر على القاعدة التي طابقت فعليًا، لا التي قصدت مطابقتها. على المنصتين تُقيَّم قواعد NAT بترتيب معين، وقد تفوز قاعدة أسبق قبل أن يُنظر إلى استثنائك. الاستثناء الذي يبدو صحيحًا لكنه يخسر أمام قاعدة أخرى لا يسلّم الحزمة المتوقعة إلى سياسة الحماية أبدًا. العَرَض مطابق لغياب الاستثناء، ولذلك يجب قراءة ترتيب القواعد قبل تغيير الإعداد.

NAT الهوية في ASA قاعدة وليس تجاوزًا

في ASA، NAT الهوية هو قاعدة NAT يكون عنوانها المترجم مساويًا للأصلي. تُختار كأي قاعدة أخرى، وما زالت تُنشئ إدخال ترجمة، أي أن الحزمة لا تتخطى معالجة NAT. ما يتغير هو أن العناوين على السلك تبقى كما هي، وهذا ما تحتاجه سياسة IPsec.

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

يجب أن تطابق واجهات القاعدة وإعداد route-lookup الخاص بها تصميم التمرير. القاعدة التي تترجم العنوان بشكل صحيح لكنها تُطبَّق على زوج واجهات خاطئ لن تُختار لتدفقك. يحدد route-lookup ما إذا كانت الحزمة المترجمة تُوجَّه أو تُستخدم الوجهة الأصلية، وهذا يحدد ما إذا كانت حركة العودة تعود عبر النفق.

الوصول الإداري إلى ASA نفسه حالة منفصلة. إذا استخدمت NAT الهوية لحركة الإدارة، ينطبق شرط route-lookup الخاص بالإصدار، ولن يصلح استثناء واسع منسوخ من مثال VPN مشكلة SSH.

رفض ACL في NAT على IOS يعني غير مختار هنا

في IOS، يُدار NAT للإنترنت بقائمة مصادر، وتلك القائمة ACL مصنّف وليست مرشّحًا. سطر permit يختار الحركة للترجمة؛ وسطر الرفض يعني أن الحزمة غير مختارة هنا. ذلك الرفض ليس أمرًا بإسقاط الحزمة كما هو الحال في رفض داخل ACL للواجهة.

غير مختار هنا أضيق أيضًا من لا يُترجم في أي مكان. يمكن لقاعدة NAT أخرى أو واجهة أخرى أو route-map أن تترجم التدفق، لذا يجب قراءة جدول NAT كاملًا. وتحتاج الحزمة أيضًا إلى مسار، وإلى ACL تشفير يطابقها، وإلى إذن عند حدود التحكم في الوصول الفعلية.

الترتيب الأدنى في IOS يضع الرفض فوق الـpermit في القائمة نفسها ويوجّه قاعدة overload إلى تلك القائمة. عندئذ تحمي ACL التشفير الزوج نفسه الذي يستثنيه الرفض من الترجمة.

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

سؤال واحد قابل للاختبار للنموذجين

يجيب النموذجان عن السؤال نفسه: أي قاعدة طابقت هذا التدفق، وأي عناوين غادرت الواجهة؟ التقط على الواجهة الخارجية وقارن عنوان المصدر قبل البوابة وبعدها. ثم تحقق من رؤية الطرف المقابل للنفق، لأن SA قد يكون قائمًا بينما يُترجم التدفق المحمي في مكان آخر.

في ASA اعرض nat detail وجدول الترجمة؛ وفي IOS اعرض ip nat translations وعدادات ACL المطابقة. القاعدة التي لا يزداد عدّادها أبدًا لم تُختار، وهذا يشير إلى الترتيب أو الواجهة أو الاتجاه لا إلى إعداد التشفير.

أين يخطئ الإعداد عادة

الأعطال الشائعة ميكانيكية. الرفض موضوع تحت الـpermit ولا يطابق أبدًا. يُطبَّق المصنّف في الاتجاه الخاطئ، فتُترجم حركة العودة. قاعدة الهوية تغطي العناوين الصحيحة لكن زوج الواجهات الخاطئ. ACL التشفير يحمي شبكة فرعية لم تعد تطابق ما تعرضه قاعدة NAT.

سجّل زوج العناوين الأصلي والمعروض بجانب مالك القاعدة، ليرى المهندس التالي لماذا يرفض مصنّف الترجمة بينما تسمح الجدار الناري بالتطبيق. احتفظ بذلك في تذكرة التغيير لا في ملاحظة شخصية. ثم أعد تشغيل التدفق بعد أي تغيير في NAT، لأن ترتيب القواعد جزء من الإعداد حتى لو لم يتغير نص القاعدة. النفق الذي يقوم ليس دليلًا على بقاء العناوين؛ فقط الحزمة الملتقطة ورؤية الطرف المقابل بعد فك التغليف هما الدليل.