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

از نشانه شروع کنید، نه از پیکربندی

ببینید بسته کجا می‌رود، نه جایی که انتظار داشتید برود. یک ضبط روی رابط بیرونی در طول یک نشست ناموفق بسته رمزگشایی‌شده را نشان می‌دهد که با نشانی استخر هنوز دست‌نخورده به سوی درگاه ISP می‌رود، یا هیچ چیز نشان نمی‌دهد چون جست‌وجو شکست خورده است. در هر دو حالت تونل مشکل نیست.

تونل در show vpn-sessiondb سالم به نظر می‌رسد و دقیقاً همین دلیل است که مردم به اشکال‌زدایی IKE ادامه می‌دهند.

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

جست‌وجوی تونلی چه تفاوتی دارد

راهنمای سیسکو برای مسیریابی ایستا در ASA 9.23 مسیر پیش‌فرض جداگانه‌ای را برای ترافیک رمزگشایی‌شده VPN که مسیر ایستا یا آموخته‌شده ندارد مستند می‌کند. کلیدواژه tunneled آن مسیر را علامت می‌زند، بنابراین بسته رمزگشایی‌شده می‌تواند به گام بعدی متفاوتی از آنچه ASA برای انتقال خود استفاده می‌کند بیفتد. مسیرهای مشخص‌تر همچنان برنده می‌شوند، و به همین دلیل کلاینت می‌تواند از طریق درگاه داخلی به 10.0.0.0/8 برسد و بقیه چیزها را از دست بدهد.

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

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

اگر هر دو مسیر پیش‌فرض به یک گام بعدی اشاره کنند، کلیدواژه چیزی را تغییر نمی‌دهد و نشانه جابه‌جا نمی‌شود.

محدودیت‌هایی که تعیین می‌کنند کار می‌کند یا نه

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

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

ردیابی مسیر تله‌ای جداگانه است: شیء ردیابی‌شده معمولاً از مسیر پیش‌فرض معمولی محافظت می‌کند، نه تونلی.

کلیدواژه چه کاری نمی‌کند

این کلیدواژه نشانی مبدأیی را که ASA برای ساختن IKE استفاده می‌کند انتخاب نمی‌کند. نقطه پایانی بیرونی تونل از انتخاب رابط و مبدأ خود پلتفرم پیروی می‌کند و مسیر پیش‌فرض تونلی هیچ سهمی در آن تصمیم ندارد. تغییر آن phase 1 را که از نشانی اشتباه می‌آید ترمیم نمی‌کند.

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

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

مسیر را سرتاسر بررسی کنید

پس از قرار گرفتن مسیر، چهار چیز را به ترتیب بررسی کنید: show route برای مقصدی که استخر نیاز دارد، یک ضبط روی رابط به سوی گام بعدی جدید، یک ضبط روی خود درگاه، و مسیر بازگشتی از آن درگاه به نشانی استخر. دو مورد اول ثابت می‌کنند که ASA مسیر را انتخاب کرده و دو مورد آخر ثابت می‌کنند که کسی روی آن پاسخ می‌دهد.

اگر درگاه پاسخ می‌دهد اما کلاینت هرگز پاسخی نمی‌بیند، پیش از دست زدن دوباره به جدول مسیریابی به ترجمه مبدأ و مسیر پاسخ نگاه کنید.

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

مقالات مرتبط