کدام رابط در خروجی VPN روی IOS نقش NAT داخلی و خارجی را می‌گیرد
بستهٔ رمزگشایی‌شدهٔ کلاینت را از رابط مجازی تا لینک بالادستی دنبال کنید. ترجمه به همان جریان داخلی تعلق دارد، نه به حمل بیرونی تونل.
روترهایی که خروجی اینترنت با تونل کامل ارائه می‌دهند، دو کار انجام می‌دهند که شبیه یکی به نظر می‌رسد. تونل را پایان می‌دهند و بستهٔ رمزگشایی‌شدهٔ کلاینت را به اینترنت می‌فرستند. تنها کار دوم به ترجمه نیاز دارد و ترجمه باید با جریان داخلی بخواند. همین تفاوت تعیین می‌کند که کدام رابط‌ها نقش‌های 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 در بالادست نیست. اولی تغییر می‌دهد که اینترنت چه چیزی را منبع درخواست کلاینت می‌بیند؛ دومی تونل را از میان یک جعبهٔ میانی زنده نگه می‌دارد.
اشتباه گرفتن این دو، دو شکست کلاسیک می‌سازد. روتری که حمل تونل خودش را ترجمه می‌کند رابطهٔ همتا را می‌شکند، و روتری که هرگز جریان داخلی را ترجمه نمی‌کند نشانی‌های خصوصی را به اینترنت می‌فرستد. پیش از ویرایش یک قاعده بخوانید که به کدام جریان نگاه می‌کنید، و بررسی کنید که آیا تونل پس از تغییر بالا مانده است. قاعده‌ای که مرور را درست می‌کند اما تونل را می‌اندازد، مشکل را جابه‌جا کرده است نه حل.
هیچ‌یک از این دو شکست با تغییر دیگری درست نمی‌شود. پیش از ویرایش یک قاعده بخوانید که به کدام جریان نگاه می‌کنید.
در هر دو مرز بررسی کنید
منبع برنامه را در مرز اینترنت بخوانید، و مقصد بازیابی‌شده را در مسیر بازگشت. اولی می‌گوید ترجمه رخ داده یا نه؛ دومی می‌گوید نگاشت معکوس به کلاینت درست برگشته یا نه.
سپس کلاینتی را آزمایش کنید که از مسیر تأییدشدهٔ تونل تقسیم‌شده استفاده می‌کند. آن کلاینت هرگز ترجمهٔ اینترنت این روتر را به کار نمی‌گیرد، پس باید متفاوت رفتار کند، و همین تفاوت تأیید می‌کند ترافیک از کدام مسیر رفته است.
اگر هر دو کلاینت یکسان رفتار کنند، خط‌مشی تونل تقسیم‌شده آنچه طراحی می‌گوید را انجام نمی‌دهد. پیش از افزودن قاعده‌های ترجمهٔ بیشتر، آن را درست کنید، چون قاعده‌ای که برای مسیری بی‌استفاده نوشته شده، مشکل واقعی را پنهان می‌کند.