ASA VPN hairpin: مسیریابی دو تونل از یک رابط

یک کاربر راه دور به ASA وصل می‌شود، میزبان پشت یک شعبه را می‌خواهد و ASA همان درخواست را از همان رابطی بیرون می‌فرستد که کاربر از آن وارد شده است. هیچ‌یک از این‌ها پورت فیزیکی دوم نمی‌خواهد. آنچه می‌خواهد چهار تصمیم مستقل است که مردم معمولاً آن‌ها را در یکی ادغام می‌کنند: اجازه hairpin، تونلی که آدرس‌های درست را محافظت کند، سیاست NAT که منبعی را که وعده داده‌اید حفظ کند و سیاست دسترسی که سرویس را مجاز می‌کند.

یک بسته، دو تونل

جریان را دنبال کنید تا ترتیب عملیات دیگر مرموز نباشد. بسته داخل تونل دسترسی راه دور می‌رسد، رمزگشایی می‌شود و به یک بسته معمولی IP با منبع از استخر کلاینت تبدیل می‌شود. سپس ASA آن را مسیریابی می‌کند، با crypto ACL سایت‌به‌سایت تطبیق می‌دهد، دوباره رمزگذاری می‌کند و از رابط بیرونی به سمت شعبه می‌فرستد.

آدرس‌های زیر نمونه‌اند، اما شکل مهم است: منبع استخر است، نه LAN داخلی ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

دو چیز از این نتیجه می‌شود. کلاینت برای پیشوند شعبه از طریق اتصال دسترسی راه دور خود به مسیر نیاز دارد، یعنی split-tunnel یا فهرست مسیرهای ارسالی باید آن را شامل شود. و شعبه باید بداند چگونه ترافیک را به 10.77.0.20 یا به آدرسی که طراحی NAT شما جایگزین کرده برگرداند.

اجازه hairpin سراسری است

دستوری که مردم به آن متوسل می‌شوند این است: same-security-traffic permit intra-interface. این دستور اجازه می‌دهد ترافیک وارد و خارج از همان رابط شود، که دقیقاً همان چیزی است که این مسیر نیاز دارد. همچنین یک تنظیم سراسری است: فعال کردن آن رفتار جریان‌های دیگری را تغییر می‌دهد که تصادفاً دو بار از همان رابط عبور می‌کنند.

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

دامنه حفاظت و NAT از هم جدا هستند

تونل سایت‌به‌سایت هر چیزی را که crypto ACL آن انتخاب کند محافظت می‌کند. اگر آن ACL زیرشبکه داخلی ASA را به‌عنوان منبع نام ببرد، استخر دسترسی راه دور محافظت نمی‌شود و بسته یا دور انداخته می‌شود یا به‌صورت واضح فرستاده می‌شود، بسته به رفتار پلتفرم در برابر ترافیک بی‌تطبیق. وقتی طراحی آدرس‌های استخر را حفظ می‌کند، استخر را به جریان محافظت‌شده اضافه کنید.

سپس NAT تصمیم می‌گیرد آدرس استخر زنده می‌ماند یا نه. Identity NAT آن را نگه می‌دارد و شعبه 10.77.0.20 را به‌عنوان منبع می‌بیند. ترجمه قرارداد را عوض می‌کند: شعبه اکنون ترافیک را به آدرس ترجمه‌شده برمی‌گرداند و سیاست خودش باید آن را بپذیرد. ترتیب قواعد تعیین می‌کند که crypto ACL پیش از ترجمه تطبیق می‌یابد یا پس از آن، پس جریان مؤثر را بخوانید نه اینکه فرض کنید کدام برنده است.

برای اینکه یک مورد عبور کار کند، قواعد عمومی PAT اینترنت را حذف نکنید. یک استثنای هدفمند یا یک قاعده identity آگاهانه آسان‌تر از یک حفره در سیاست خروج قابل توضیح و برگشت است.

رمزگذاری مجوز نیست

تونل کارکننده فقط ثابت می‌کند دو طرف بر سر کلیدها و انتخابگرها توافق دارند. هیچ نمی‌گوید آیا این کاربر می‌تواند به آن سرویس برسد. فیلتر VPN یا سیاست گروهی متصل به اتصال دسترسی راه دور هنوز باید مقصد و پورت شعبه را مجاز کند و ACL رابط در مسیر بیرونی هنوز اعمال می‌شود.

پاسخ را در هر دو جهت آزمایش کنید. اتصالی که موفق می‌شود در حالی که یک سرویس مجاور باید شکست بخورد، آموزنده‌تر از یک ping موفق است، چون نشان می‌دهد سیاست گزینشی است نه کاملاً باز. اگر آزمایشی که باید رد شود موفق شود، تونل مقصر نیست؛ سیاست مقصر است. هر دو نتیجه را در سابقه تغییرات نگه دارید تا نفر بعد بداند کدام رفتار مورد نظر بوده است.

hairpin یا رابط دوم

عبور hairpin طراحی را کوچک نگه می‌دارد و فقط یک تنظیم سراسری هزینه دارد. یک رابط جداگانه یا تونل مبتنی بر مسیریابی با رابط مجازی خودش، مسیر عبور را جدا می‌کند و سیاست به‌ازای هر رابط می‌دهد، به بهای آدرس‌دهی و یک crypto map یا پروفایل دیگر. هیچ‌یک درست‌تر نیست؛ متفاوت شکست می‌خورند.

طراحی‌های مبتنی بر مسیریابی چیدمان دیگری هستند، نه یک کادر انتخاب در همان پیکربندی. اگر به یکی از آن‌ها بروید، بحث crypto ACL مبتنی بر سیاست بالا دیگر کاربرد ندارد و جدول مسیریابی کار انتخاب را انجام می‌دهد.

از کلاینت واقعی بررسی کنید

کاوشگری که از ASA آغاز شود آدرس منبع متفاوتی دارد و مسیر استخر به شعبه را تمرین نمی‌دهد. از packet-tracer برای بررسی پنج‌تایی استفاده کنید، سپس از کلاینت راه دور واقعی یک اتصال حقیقی باز کنید، چون ردیاب شبیه‌سازی می‌کند و جای مسیریابی و سیاست خود کلاینت را نمی‌گیرد.

پس از یک تغییر برنامه‌ریزی‌شده، به سرویسی که باید کار کند وصل شوید، سپس به یکی که باید رد شود، و بعد مسیر بازگشت شعبه را تأیید کنید. نمونه‌های NAT hairpin سیسکو برای VPN اجازه intra-interface، NAT و ACLها را به‌صورت دیدنی جدا نگه می‌دارند و این همان مدل ذهنی است که ارزش کپی کردن دارد.