تحریک پورت در مقابل ارسال پورت برای سرور VPN خانگی
تحریک پس از ترافیک خروجی یک نگاشت باز می‌کند؛ ارسال، پورت را دائمی نگاشت می‌کند. سرور VPN خانگی به دومی نیاز دارد، محدود به شنونده واقعی.
ارسال پورت و تحریک پورت در بیشتر روترهای خانگی در یک منو قرار دارند، و همین است که آن‌ها را دو راه برای یک کار می‌پندارند. ارسال یک قاعده ایستا است: اتصال ورودی به یک پورت WAN به نشانی و پورت داخلی ثابت ترجمه می‌شود، چه چیز دیگری در جریان باشد چه نه. تحریک شرطی است: روتر ترافیک خروجی را می‌پاید و تنها پس از خروج یک اتصال منطبق، یک نگاشت ورودی باز می‌کند. سرور VPN منتظر می‌ماند که نخست کس دیگری متصل شود، پس همان شرط تنها چیزی است که هرگز نمی‌تواند برآورده کند.
دو قاعده با چرخه‌های عمر متفاوت
NAT در IPv4 حالت‌مند است. وقتی میزبان داخلی بسته‌ای به بیرون می‌فرستد، روتر نگاشتی می‌سازد تا پاسخ‌ها راه بازگشت را پیدا کنند؛ بسته ورودی که با هیچ نگاشتی منطبق نیست دور انداخته می‌شود، و همین رفتار رایانه رومیزی به‌روزنشده را از اینترنت بیرون نگه می‌دارد. ارسال یک درایه ترجمه دائمی است که دستی افزوده می‌شود. تحریک یک سوراخ موقت است که الگویی از ترافیک از آن نگهبانی می‌کند.
تفاوت عملی زمان است. ارسال از لحظه ذخیره شدن تا وقتی کسی آن را حذف کند وجود دارد. نگاشت تحریک‌شده پس از فعال شدن محرک وجود دارد و با یک زمان‌سنج بی‌کاری بسته می‌شود، که روی سخت‌افزار مصرفی با دقیقه سنجیده می‌شود، یا بلافاصله هنگام راه‌اندازی دوباره.
هیچ‌کدام در حالت انتزاعی امن‌تر نیست. ارسال یک پورت را پیوسته در معرض می‌گذارد؛ محرک آن را تنها پس از ترافیک خروجی مشخصی در معرض می‌گذارد. برای سرویسی که باید نخستین بسته را از یک غریبه بپذیرد، تنها یکی از این دو با کار جور است.
چرا تحریک یک سرور را منتشر نمی‌کند
سرور VPN به‌طور طراحی منفعل است. همتا، چه رایانه کیفی در کافه باشد چه گوشی روی داده همراه، نخستین بسته را می‌فرستد و روتر هیچ نگاشتی برای آن ندارد. هیچ چیز در داخل، ترافیکی به پورت محرک آغاز نکرده است، پس قاعده هرگز فعال نمی‌شود و اتصال پیش از آغاز دست‌دهی می‌میرد.
جایی که تحریک کار می‌کند به نظر می‌رسد، چیز دیگری روی پورت محرک ترافیک تولید می‌کند: یک کارخواه در LAN، یک کاوشگر پایش، یا بررسی‌های خروجی خود سرور. آن‌گاه نگاشت برای همان یک میزبان باز می‌شود و با توقف ترافیک بسته می‌شود، پس همتای بیرونی بعدی دوباره شکست می‌خورد در حالی که موفقیت نخست در گزارش می‌نشیند و مانند مدرک به نظر می‌رسد.
تحریک همچنین معمولاً تک‌میزبانی است. بسیاری از پیاده‌سازی‌ها تنها به یک دستگاه داخلی اجازه می‌دهند نگاشت را در هر زمان نگه دارد، که برای سروری که باید به چند همتا پاسخ دهد کاملاً نادرست است. این ویژگی برای برنامه‌هایی ساخته شد که یک اتصال کنترلی به بیرون باز می‌کنند و داده ورودی روی پورت دومی را انتظار دارند، و هنوز با همان شکل جور است.
ارسال در واقع چه چیزی را نگاشت می‌کند
ارسال یک درایه ترجمه است: پورت و پروتکل WAN به نشانی و پورت داخلی. به شنونده‌ای نیاز دارد که از پیش در آن سوی دیگر در حال اجرا باشد، و به آن نیاز دارد که نشانی داخلی سر جای خود بماند. اجاره DHCP که به ماشین دیگری جابه‌جا شود، هر تونل را بی‌صدا به میزبان نادرست می‌فرستد، پس رزرو را پیش از قاعده بسازید.
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
پروتکل بیش از آنچه فرم می‌نماید اهمیت دارد. OpenVPN روی UDP به ارسال UDP نیاز دارد، WireGuard به UDP نیاز دارد و داده IPsec به شکل ESP، پروتکل IP شماره 50 می‌رسد، که هیچ پورتی ندارد. فرم ارسالی که تنها TCP یا UDP را می‌پذیرد نمی‌تواند این را بیان کند، پس IPsec به passthrough یا نگاشت ایستای یک‌به‌یک به‌جای قاعده پورت نیاز دارد.
لایه بالای روتر شما
ارسال تنها ترجمه‌ای را که مال شماست کنترل می‌کند. اگر نشانی WAN مال شما نباشد، که پشت NAT اپراتور چنین است جایی که مشترکان 100.64.0.0/10 را شریک می‌شوند چنان‌که در RFC 6598 توصیف شده، اتصال ورودی هرگز به روتر شما نمی‌رسد چون ارائه‌دهنده نخست ترجمه کرده است. هیچ قاعده‌ای روی دستگاه شما نمی‌تواند آن ترتیب را درست کند.
NAT دوگانه همان مشکل در مقیاس کوچک است. روتر شما به روتر ISP ارسال می‌کند که قاعده منطبقی ندارد و بسته را دور می‌اندازد. یا قاعده را روی دستگاه بیرونی بیفزایید، یا دستگاه بیرونی را در حالت پل بگذارید و بگذارید دستگاه خودتان نشانی عمومی را نگه دارد.
به همین دلیل آزمون باید از بیرون بیاید. آزمون از همان LAN از راه نشانی عمومی به پشتیبانی hairpin NAT وابسته است و می‌تواند به دلایلی بی‌ربط به قاعده بگذرد یا شکست بخورد؛ گوشی روی داده همراه، یا دوستی در شبکه‌ای دیگر، بررسی پاکیزه‌تری است.
قاعده را محدود کنید، سپس هر دو نیمه را بسنجید
یک پورت را به یک نشانی ارسال کنید. بازه‌ای که چون تلاش‌های نخست شکست خورد افزوده شده، همان راهی است که رابط‌های مدیریت به اینترنت می‌رسند، و شنونده VPN به صفحه مدیریت روتر در کنار خود منتشرشده نیازی ندارد.
هر چیزی را که پیش‌تر از آن شنونده محافظت می‌کرد نگه دارید: هویت گواهی یا کلید، دیوار آتش میزبان، نسخه‌های به‌روز بسته‌ها. ارسال یک بسته را می‌پذیرد؛ احراز هویت تعیین می‌کند که بسته به تونل تبدیل می‌شود یا نه، و این‌ها دو شکست جدا هستند وقتی چیزی اشتباه پیش می‌رود.
سنجش دو نیمه دارد. دست‌دهی باید از شبکه‌ای بیرونی کامل شود، و سپس منبعی خصوصی پشت سرور باید از راه تونل پاسخ دهد. ارسال اتصال تونل را می‌پذیرد و نه بیشتر؛ مسیریابی و مجوزدهی برای 10.8.0.0/24 تنظیم دیگری روی صفحه‌ای دیگر است.
با سه پرسش تصمیم بگیرید
سه پرسش انتخاب را سریع‌تر از هر جدول مقایسه‌ای حل می‌کند:
- آیا چیزی از بیرون به‌عنوان نخستین بسته متصل می‌شود؟ پس از ارسال، یا یک رله استفاده کنید. تحریک بدون ترافیک خروجی که هرگز وجود نخواهد داشت باز نمی‌شود.
- آیا سوراخ باید بیش از زمان بی‌کاری بماند؟ پس از ارسال استفاده کنید، زیرا نگاشت تحریک‌شده بر اساس برنامه خودش بسته می‌شود.
- آیا نشانی WAN مال شما است تا منتشرش کنید؟ اگر نیست، پیش از ویرایش هر قاعده‌ای لایه بالاتر را درست کنید.
اگر پاسخ هر سه پرسش نه باشد، که مورد رایانه کیفی است که خودش به ارائه‌دهنده‌ای تجاری زنگ می‌زند، هیچ‌یک از دو قاعده لازم نیست. کارخواهی پشت NAT کار می‌کند چون خودش نگاشت حالت‌مند را می‌سازد، و این بیشتر کسانی را در بر می‌گیرد که نیمه‌شب صفحه ارسال پورت را می‌خوانند.