ASA hairpin: خروج به اینترنت یا شاخهٔ VPN سایت‌به‌سایت؟

دو کاربر دسترسی از راه دور پشت یک ASA می‌توانند ترافیک را از همان رابط بیرونی ارسال کنند و کاملاً متفاوت رفتار ببینند. یکی به یک وب‌سایت عمومی می‌رود، پس بسته به ترجمهٔ مبدأ و مسیر اینترنت نیاز دارد. دیگری به سروری پشت یک تونل سایت‌به‌سایت می‌رود که آن هم روی همان رابط پایان می‌یابد، پس بسته به هویت، انتخابگر تونل مطابق و مسیر بازگشت به استخر کلاینت نیاز دارد. اجازهٔ همان رابط برای هر دو پیش‌شرط است و برای هیچ‌کدام راه‌حل نیست.

دو شاخه، یک رابط

پیش از تایپ قانون NAT تصمیم بگیرید کدام شاخه را می‌سازید، چون قوانین قابل تعویض نیستند. شاخهٔ A از کلاینت به اینترنت است: آدرس استخر وارد، آدرس عمومی ترجمه‌شده خارج، و بازگشت از همان رابط. شاخهٔ B از کلاینت به یک پیشوند خصوصی در طرف دور یک همتای IPsec دیگر است: آدرس استخر حفظ می‌شود، دوباره رمزگذاری می‌شود و به همتایی تحویل می‌شود که باید بداند چگونه به استخر پاسخ دهد.

چیزی که هر دو نخست نیاز دارند اجازهٔ همان رابط است. بدون آن ASA از ارسال بسته از رابطی که بسته در آن رسیده خودداری می‌کند و خرابی شبیه یک مشکل مسیریابی به نظر می‌رسد نه یک مشکل سیاست:

same-security-traffic permit intra-interface

همان یک خط آرایش ارسال را مجاز می‌کند، همان‌گونه که مرجع NAT در ASA برای مسیرهای همان رابط توصیف می‌کند. این خط هیچ مسیر کلاینتی اضافه نمی‌کند، هیچ منبعی را مجاز نمی‌کند، هیچ آدرسی را ترجمه نمی‌کند و دربارهٔ انتخابگر IPsec مذاکره نمی‌کند، پس انتظار داشته باشید پس از آن سه یا چهار چیز دیگر اضافه کنید و پذیرش آن را پیشرفت نخوانید.

شاخهٔ A: کلاینت اینترنت می‌خواهد

برای خروج به اینترنت، آدرس استخر باید پیش از خروج بسته از دستگاه دیگر خصوصی نباشد. در یک طراحی معمول PAT قانون استخر را به آدرس رابط بیرونی ترجمه می‌کند و وضعیت بازگشت جریان رو به کلاینت را بازمی‌گرداند:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

سپس تأیید کنید که کلاینت واقعاً از ASA خواسته است این ترافیک را حمل کند. استثنای تونل تقسیم‌شده مقصد عمومی را از طریق اتصال خودِ تلفن می‌فرستد که هرگز به ASA نمی‌رسد، و هیچ قانون NAT بسته‌ای را که هرگز فرستاده نشده ترمیم نمی‌کند. فهرست تونل تقسیم‌شدهٔ سیاست گروه را با مقصدی که آزمایش می‌کنید مقایسه کنید.

بقیهٔ شاخه معمولی است: یک مسیر پیش‌فرض یا مشخص قابل استفاده از رابط بیرونی، یک سیاست دسترسی که جریان را مجاز می‌کند، و DNS که بر اساس سیاست حل‌کننده‌ای که انتخاب کرده‌اید اداره می‌شود. اضافه کنید route-lookup را اینجا به همان دلیل زیر، چون رابط ورود و خروج یکسان است.

شاخهٔ B: کلاینت یک سایت خصوصی می‌خواهد

این شاخه در جاهای بیشتری شکست می‌خورد، پس آن را به ترتیب بنویسید. نخست مسیر کلاینت: پیشوند مقصد باید در فهرست تونل تقسیم‌شده باشد، وگرنه کلاینت آن را در تونل قرار نمی‌دهد. دوم انتخابگر تونل: ACL رمزنگاری سایت‌به‌سایت باید آدرس استخر تا پیشوند دور را پوشش دهد، نه فقط LAN محلی تا پیشوند دور. سوم هویت، تا آدرس استخر در مسیر به PAT اینترنت ترجمه نشود.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

طرف دور بخشی است که مردم فراموش می‌کنند آزمایش کنند. همتا به مسیری بازگشتی به استخر و انتخابگری که آن را در بر بگیرد نیاز دارد، و سیاست خودش باید آدرس‌های مبدأیی را که خواهد دید مجاز کند. اگر سایت در عوض از طریق نمای ترجمه‌شده استفاده شود، طراحی معتبری است، اما آن‌گاه هر دو همتا، هر دو انتخابگر و هر دو جدول مسیریابی باید دربارهٔ آدرس‌های ترجمه‌شده توافق داشته باشند.

ترتیب قوانین را هم بررسی کنید. یک قانون PAT گسترده بالای قانون هویت، تبادل خصوصی را پیش از آنکه قانون هویت ارزیابی شود ترجمه می‌کند، و نشانهٔ آن یک تونل سایتی بدون SA مطابق است نه یک خطای NAT.

آزمایشی که می‌گوید کدام شاخه را ساخته‌اید

به‌جای خواندن پیکربندی و امیدوار بودن، از ارزیابی مسیر خود ASA استفاده کنید. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed تصمیم NAT، مسیر و نتیجهٔ ACL را برای یک جریان نشان می‌دهد؛ آن را با مقصدی خصوصی تکرار کنید. اگر مرحلهٔ NAT جریان خصوصی‌به‌خصوصی را بازنویسی کند، شاخهٔ A را برای بسته‌ای ساخته‌اید که به شاخهٔ B نیاز داشت.

دو فرمان دیگر شکاف را می‌بندند. show nat detail ترتیب قوانینی را که packet-tracer دنبال کرده چاپ می‌کند، و show crypto ipsec sa نشان می‌دهد آیا انتخابگری برای جفتی که انتظار دارید وجود دارد. SA غایب مسئلهٔ پیکربندی انتخابگر یا همتاست، نه چیزی که قانون NAT بتواند ترمیم کند.

هر شاخه را با ترافیکی که خدمت می‌کند تأیید کنید

شاخهٔ A را با یک درخواست عمومی معمول از کلاینت بپذیرید و شاخهٔ B را با درخواستی به یک منبع خصوصی که واقعاً وجود دارد. سپس هر یک را با منبعی ردشده تکرار کنید، چون «مجاز» و «تأییدشده توسط سیاست دسترسی» شاهد یکسانی نیستند، و pingی که از مرکز آغاز شود هیچ‌یک از مسیرهای کلاینت را تمرین نمی‌دهد.

دو سابقهٔ آزمایش را جداگانه در تیکت نگه دارید: آدرس مبدأ، مقصد، قانون NAT که مطابقت کرد و نتیجه. وقتی گزارش بعدی می‌گوید «VPN خراب است»، آن جفت در عرض یک دقیقه به شما می‌گوید کدام شاخه پسرفت کرده است، و پاسخ معمولاً یک مسیر یا یک انتخابگر است نه خط همان رابط که همه نخست به آن شک می‌کنند.