VPN پشت NAT که نمی‌توانید پیکربندی کنید: چه چیزی هنوز کار می‌کند

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

جدول نگاشت همه‌چیز را تعیین می‌کند

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

از سمت روتر به جدول نگاه کنید و راه‌حل‌ها آشکار می‌شوند: یا چیزی یک ثبت دائمی می‌سازد، یا یک ثبت موقت می‌سازد و آن را تازه نگه می‌دارد، یا ترافیک اصلاً آن مسیر را نمی‌رود. باقی این مقاله همان سه حالت به ترتیب است. هیچ‌چیز اینجا به ویژگی‌ای از فروشنده فراتر از آنچه جدول ثبت می‌کند وابسته نیست.

خدمات قرار چه می‌تواند بکند و چه نمی‌تواند

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

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

Keepalive، راه‌اندازی مجدد و نقطه پایانی که جابه‌جا می‌شود

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

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

سه راه دور زدن انتقال پورت غایب

راه اول از روتر می‌خواهد خودش ثبت را بسازد، از طریق UPnP IGD، NAT-PMP یا PCP، وقتی این ویژگی وجود دارد و روشن است. راه دوم ترافیک را به یک رله با نشانی عمومی می‌سپارد که همیشه کار می‌کند و همیشه هزینه پهنای باند به‌علاوه یک مرز اعتماد متفاوت دارد. راه سوم جهت را برمی‌گرداند: میزبان داخلی یک تونل خروجی به یک سرور عمومی باز می‌کند و بقیه چیزها داخل آن سوار می‌شوند.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

راه‌حل را با مالک روتر هماهنگ کنید

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

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