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

پنج فیلد را پیش از نوشتن فرمان بنویسید

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

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

Public entryOwnerReal side
TCP 443 on the outside addressASA VPN listenerAppliance-local, no translation
TCP 8443 on the outside addressStatic PATDMZ server TCP 443
UDP 443 on the outside addressCheck the effective listenersPossibly the VPN data path

موقعیت‌های واقعی و نقشه‌برداری‌شده را درست بخوانید

از چندتایی‌ای شروع کنید که از قبل دارید، نه از سروری که می‌خواهید اضافه کنید. یک تقسیم نمونه ورودی تأییدشده VPN را روی TCP 443 عمومی نگه می‌دارد و سرور DMZ HTTPS را روی TCP 8443 عمومی منتشر می‌کند، در حالی که آن سرور به گوش دادن روی 443 ادامه می‌دهد:

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

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

راهنمای NAT نسخه 9.16 ASA شرکت Cisco، PAT استاتیک، استفاده از نشانی رابط و معنای پورت واقعی در برابر نقشه‌برداری‌شده را مستند می‌کند. بخش مربوط به نسخه‌ای را بخوانید که واقعا اجرا می‌کنید؛ فرمانی که از پلتفرم قدیمی‌تر به یاد مانده، پیکربندی کامل کنونی نیست.

ترانسپورت را بخشی از رزرو حساب کنید

TCP 443 و UDP 443 چندتایی‌های متفاوتی هستند، و این تفاوت UDP را مجانی به شما نمی‌دهد. یک VPN ممکن است شنونده‌های جداگانه TLS و DTLS داشته باشد، و سرویس‌های پیکربندی‌شده دیگر ممکن است ترانسپورتی را که می‌خواهید در اختیار داشته باشند. شنونده‌های مؤثر و سیاست دسترسی را فهرست کنید، به‌جای اینکه فرض کنید صفحه وب تمام ورودی VPN است.

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

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

از بیرون با اتصال‌های تازه تأیید کنید

فقط برنامه DMZ موردنظر را زیر سیاست دسترسی مؤثر مجاز کنید، سپس ترتیب ترجمه مطابق، مسیر بازگشت سرور و نام میزبان روی گواهی را بررسی کنید. PAT مقصد شبکه را تغییر می‌دهد؛ دسترسی به برنامه نمی‌دهد و گواهی‌ای را که میزبان دیگری را نام می‌برد تعمیر نمی‌کند.

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

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

مقالات مرتبط