أي واجهة تأخذ دور NAT الداخلي والخارجي عند مخرج VPN على IOS
تابع حزمة العميل المفكوكة التشفير من الواجهة الافتراضية إلى الوصلة الصاعدة. الترجمة تنتمي إلى ذلك التدفق الداخلي، لا إلى النقل الخارجي للنفق.
الموجّهات التي توفّر مخرجًا إلى الإنترنت عبر نفق كامل تؤدي مهمتين تبدوان وكأنهما مهمة واحدة. فهي تُنهي النفق، وتمرّر حزمة العميل المفكوكة التشفير إلى الإنترنت. المهمة الثانية وحدها تحتاج إلى ترجمة، والترجمة يجب أن تطابق التدفق الداخلي. وهذا التمييز يحدّد الواجهات التي تحمل أدوار NAT ونطاق العناوين الذي يظهر في القاعدة.
تابع حزمة واحدة عبر الموجّه
خذ عميلًا على 10.90.0.25 يفتح خدمة HTTPS عامة. أما دخول تلك الوجهة في النفق أصلًا فهو قرار سياسة العميل نفسه. وبعد أن يحدث ذلك، يفكّ الموجّه تشفير الحزمة ويسلّمها إلى واجهة افتراضية، لتُوجَّه من هناك إلى الوصلة الصاعدة العامة.
تلك الواجهة الافتراضية هي الجانب الداخلي للترجمة. والوصلة الصاعدة العامة هي الجانب الخارجي. وإذا عُكست الأدوار أو غابت، فإن الحزمة إما تخرج بمصدر خاص وإما تُسقَط قبل ترجمتها.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
طابق سياسة الترجمة مع مجموعة العملاء
يجب أن تسمّي قاعدة NAT النطاق الذي يتلقاه العملاء فعليًا، لا شبكة LAN المكتبية التي تصادف أنها تشترك في الوصلة الصاعدة. فالقاعدة التي تغطي الشبكة الفرعية المحلية وحدها تُغفل العملاء البعيدين حتى لو كان الطرفان يخرجان عبر الواجهة نفسها.
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadأبقِ استثناءات المواقع الخاصة منفصلة. فحركة المرور إلى الوجهات الداخلية يجب أن تحتفظ بمصدرها الأصلي، وإلا ردّت الوجهة على عنوان لا تستطيع الوصول إليه، وفشل مسار العودة على نحو يبدو كحلقة توجيه.
طبّق الأدوار على الواجهات الفعلية في التصميم المنشور. فجزء Virtual-Template منسوخ من إجابة Easy VPN قديمة ليس إعدادًا حاليًا كاملًا، ونوع النفق المستخدم يحدّد الواجهة التي تتلقى الحزمة المفكوكة التشفير.
افصل النقل الخارجي عن الترجمة الداخلية
ترجمة مصدر تطبيق بعد فك التشفير ليست العملية نفسها التي تدفع بها حزم IKE أو الحزم المحمية عبر جهاز NAT في المنبع. فالأولى تغيّر ما يراه الإنترنت مصدرًا لطلب العميل؛ والثانية تُبقي النفق حيًا عبر صندوق وسيط.
الخلط بينهما يُنتج فشلين كلاسيكيين. فالموجّه الذي يترجم نقل نفقِه الخاص يكسر علاقة النظير، بينما الموجّه الذي لا يترجم التدفق الداخلي أبدًا يمرّر عناوين خاصة إلى الإنترنت. اقرأ أي تدفق تنظر إليه قبل تعديل قاعدة، وتحقق مما إذا بقي النفق قائمًا بعد التغيير. فالقاعدة التي تُصلح التصفح بينما تُسقط النفق تكون قد نقلت المشكلة بدل أن تحلّها.
لا يُصلح أي من الفشلين بتغيير الآخر. اقرأ أي تدفق تنظر إليه قبل تعديل قاعدة.
تحقق عند الحدّين
اقرأ مصدر التطبيق عند حدود الإنترنت، والوجهة المستعادة في مسار العودة. فالأول يخبرك هل حدثت الترجمة؛ والثاني يخبرك هل عاد التعيين العكسي إلى العميل الصحيح.
ثم اختبر عميلًا يستخدم مسار نفق منقسم معتمدًا. فذلك العميل لا يمارس ترجمة الإنترنت لهذا الموجّه إطلاقًا، لذا ينبغي أن يتصرف بشكل مختلف، والاختلاف يؤكد المسار الذي سلكته الحركة.
إذا تصرف العميلان بالطريقة نفسها، فسياسة النفق المنقسم لا تفعل ما يقوله التصميم. أصلح ذلك قبل إضافة مزيد من قواعد الترجمة، لأن قاعدة مكتوبة لمسار غير مستخدم تُخفي المشكلة الحقيقية.