نشر خدمة داخلية عبر شبكة VPN من موقع إلى موقع على ASA
خمسة فحوص مرتبة لكشف خدمة داخلية عبر شبكة VPN من موقع إلى موقع على ASA: النطاق المحمي، نموذج المصدر، الترجمة، نطاق المنفذ، مسار الرد.
نشر خدمة تقع خلف شبكة VPN من موقع إلى موقع مهمة واحدة فيها خمس نقاط فشل، وهي تفشل بترتيب ثابت. يأتي النفق، وتطابق الترجمة، ويجيب الفرع، ويعود الرد عبر المسار نفسه. وحين يكون أي منها خاطئًا يظهر في المتصفح الشيء نفسه: اتصال يتعلق أو يُعاد ضبطه. اعمل القائمة من الأعلى إلى الأسفل وتوقف عند أول فحص يفشل.
الفحص 1: النفق يحمي عنوان الأصل
ابدأ من نفق يمرر حركة المرور بالفعل، ثم تأكد من أن العنوان الذي تخطط لنشره يقع داخل النطاق المحمي. على ASA يأتي ذلك النطاق من قائمة ACL الخاصة بالتشفير أو من مسارات VTI، وعليه أن يغطي العنوان الحقيقي للأصل لا الشبكة الفرعية التي يستخدمها الفرع للإدارة. المحدِّد الذي يفوّت الأصل يمنحك نفقًا قائمًا وتدفقًا لا يدخله أبدًا.
تأكد من ذلك عبر عدادات النفق وجدول المسارات قبل أن تمس الترجمة. إن كان الأصل غير قابل للوصول من المحور عبر النفق، فلا شيء لاحق في هذه القائمة يمكنه إصلاح ذلك.
توقف هنا إذا لم يتفق النطاق المحمي وعنوان الأصل.
الفحص 2: قرر أي مصدر سيراه الفرع
يرى الفرع إما عنوان العميل الأصلي وإما عنوانًا مترجمًا، وهذا الاختيار يحدد مسار العودة. الحفاظ على عنوان العميل يبدو أنظف في سجلات الأصل، لكن على الفرع حينئذ أن يرسل ردود العملاء العامين عبر النفق؛ أما المسار الافتراضي العادي للإنترنت فيرسلها في الاتجاه الآخر ويموت الاتصال في اتجاه واحد. وترجمة المصدر إلى عنوان يوجهه الفرع أصلًا عبر النفق تزيل هذا الشرط.
تغيّر الترجمة أيضًا ما يمكن للأصل تسجيله وما يمكن لقواعد المصدر مطابقته. إن كان التطبيق يحتاج إلى معرفة الشخص وراء الطلب، فمكان ذلك وكيل عكسي موثَّق، لا قرار NAT.
الفحص 3: اكتب الترجمة مقابل الواجهات الحقيقية
يقيّم ASA قواعد الترجمة بالترتيب ويبلّغ أيها طابق، لذا فزوج الواجهات داخل القاعدة ليس شكليًا. القاعدة المكتوبة لمسار من الخارج إلى الداخل لن تطابق تدفقًا يختلف دخوله وخروجه عن الذي افترضته.
المسار الذي تبنيه له أربعة أجزاء، ويجب أن تتفق الأربعة:
| Leg | Source | Destination |
|---|---|---|
| Request from the internet | 198.51.100.25 | 203.0.113.20:443 |
| After destination translation | 198.51.100.25 | 10.60.20.10:443 |
| After source translation toward the tunnel | 10.10.250.10 | 10.60.20.10:443 |
| Branch reply | 10.60.20.10 | 10.10.250.10 |
| Restored reply to the client | 203.0.113.20 | 198.51.100.25 |
اعتبر النطاقات في ذلك الجدول عناصر نائبة. المهم أن الصف بعد الترجمة عنوان يقبله الفرع عبر النفق، وأن التعيين العكسي موجود في حالة NAT بحيث يُستعاد الرد عند الخروج.
الفحص 4: احصر قاعدة الوصول في المنفذ المنشور
انشر المنفذ، لا المضيف. القاعدة التي تسمح للأصل على كل خدمة تحوّل تطبيقًا منشورًا واحدًا إلى مسار إلى كل ما يشغله الأصل، بما في ذلك واجهة الإدارة التي أبعدتها عن الإنترنت عمدًا. اسمح بالمنفذ المنشور من المصدر المترجم إلى الأصل، واترك الخدمات الإدارية على مسارها الخاص بـ VPN فحسب.
افحص ترتيب القواعد في الوقت نفسه. السماح الواسع الجالس فوق قاعدتك المحددة يجعل القاعدة المحددة غير مرئية.
الفحص 5: تتبّع طلبًا واحدًا ورده
لا تبدأ بمتصفح، لأن المتصفح يخفي أي جزء فشل. تتبّع التدفق على المحور واقرأ النتيجة قبل أن تغيّر أي شيء.
packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2lيسمّي التتبع الترجمة التي طابقت، وقاعدة الوصول التي سمحت بالتدفق أو رفضته، وما إذا كانت الحزمة قد وُجّهت إلى النفق. إن أظهر أن التدفق يخرج من واجهة لم تتوقعها، فزوج الواجهات في قاعدة NAT خاطئ. وإن أظهر رفضًا، فترتيب القواعد خاطئ. وإن وصل إلى النفق ولم يجب الأصل أبدًا، فمشكلة مسار العودة في الفرع.
ثم أرسل طلبًا حقيقيًا واحدًا من الخارج وتأكد من أن الرد يعود عبر النفق نفسه. سجّل الإدخال المنشور والترجمة وزوج العناوين المحمي ومسار العودة بوصفها سجل النشر.