همه چیز را به یک میزبان هدایت کنیم یا پورت را هم بازنویسی کنیم؟

هدایت همه چیز به سرور VPN شما می‌تواند دو قاعده بسیار متفاوت را توصیف کند. یکی نشانی مقصد را تغییر می‌دهد و پورت ورودی را نگه می‌دارد؛ دیگری پورت را نیز به یک شنونده واحد بازنویسی می‌کند. میزان قرارگیری در معرض خطر یکسان نیست و تصمیم به سه شرط بستگی دارد، نه به برچسبی که رابط روتر استفاده می‌کند.

شرط یکم: قاعده کدام فیلدها را تغییر می‌دهد؟

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

قاعده واقعی را بخوانید، نه برچسب منو را. صفحه‌ای که می‌گوید DMZ یا همه پورت‌ها، یک قصد را توصیف می‌کند نه مسیر بسته. مستندات Netfilter NAT دو ترجمه را از هم جدا می‌کند و این مدل ذهنی درست است حتی وقتی روتر پیش روی شما یک دستگاه مصرفی باشد.

دو فیلد، دو پرسش متفاوت.

شرط دوم: چه چیزی روی پورت‌های حفظ‌شده گوش می‌دهد؟

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

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

پیش از انتخاب، شنونده را فهرست کنید.

شرط سوم: ورودی بیرونی چقدر گسترده است؟

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

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

نقطه پایانی ترجمه‌شده را کامل بنویسید: پروتکل، پورت بیرونی، نشانی درونی، پورت درونی.

چیزی که هیچ‌یک از دو قاعده به شما نمی‌دهد

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

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

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

با نقطه پایانی ترجمه‌شده در دست تصمیم بگیرید

نتیجه قاعده را به صورت جمله بنویسید: پورت عمومی UDP X به نشانی Y پورت Z می‌رسد. سپس بپرسید کدام سرویس‌ها در Y می‌توانند روی Z پاسخ دهند و مالک آن‌ها کیست.

nft list ruleset

اگر پاسخ همان یک شنونده‌ای است که در نظر داشتید، قاعده کار خود را انجام می‌دهد.

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