آیا روتر بالادست واقعاً پورت‌های ورودی VPN را تحویل می‌دهد؟

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

سه پاسخ تعیین می‌کند به چه کسی ارجاع دهید

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

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

تحویل را مانند قرارداد سرویس بخوانید

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

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

یک تلاش را در هر دو مرز مشاهده کنید

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

tcpdump -ni wan0 'tcp port 1194 and host 203.0.113.10'

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

نبود شاهد در یک ضبط اثبات وجود دیوار آتش نیست. این یک نتیجه مرزی است که می‌گوید بعدی کدام دستگاه را بررسی کنید.

نگذارید NAT محلی پاسخ را پنهان کند

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

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

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