انتشار یک سرویس داخلی از طریق VPN سایت به سایت روی ASA

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

بررسی 1: تونل از نشانی مبدأ محافظت می‌کند

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

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

اگر محدوده محافظت‌شده و نشانی مبدأ هم‌خوان نیستند اینجا بایستید.

بررسی 2: تصمیم بگیرید شعبه کدام مبدأ را می‌بیند

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

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

بررسی 3: ترجمه را بر اساس رابط‌های واقعی بنویسید

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

مسیری که می‌سازید چهار بخش دارد و هر چهار بخش باید هم‌خوان باشند:

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

بررسی 4: قاعده دسترسی را به پورت منتشرشده محدود کنید

پورت را منتشر کنید، نه میزبان را. قاعده‌ای که مبدأ را روی هر سرویس مجاز می‌کند یک برنامه منتشرشده را به مسیری به همه چیزهایی که مبدأ اجرا می‌کند تبدیل می‌کند، از جمله رابط مدیریتی که عمداً بیرون از اینترنت نگه داشتید. پورت منتشرشده را از مبدأ ترجمه‌شده به مبدأ مجاز کنید و سرویس‌های مدیریتی را روی مسیر فقط-VPN‌شان بگذارید.

ترتیب قواعد را هم‌زمان بررسی کنید. یک مجوز گسترده که بالای قاعده مشخص شما بنشیند قاعده مشخص را نامرئی می‌کند.

بررسی 5: یک درخواست و پاسخش را ردیابی کنید

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

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

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