VPN روی روتر یا هدایت پورت: کدام برنده است؟

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

یک پورت، دو مالک ادعاشده

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

پیش از ویرایش ادعا را بنویسید: خانواده، نشانی بیرونی، ترابری، پورت و مقصد ترجمه‌شده.

ترجمه پیش از بررسی محلی اجرا می‌شود

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

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

یک نگاشت را نگه دارید و دیگری را بردارید

مدخل‌های NAT را برای آن پورت و خانواده فهرست کنید و بازمانده را برگزینید:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

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

اگر VPN روی میزبانی جدا زندگی می‌کند، هدایت شیء درست است. سرویس در یک کانتینر یا ماشین مجازی ممکن است حتی وقتی جعبه روتر نامیده می‌شود به پورت منتشرشده نیاز داشته باشد، پس سوکت و فضای نامش را دنبال کنید، نه برچسب روی جعبه.

مالک را از بیرون تأیید کنید

هر خانواده را جداگانه آزمایش کنید، چون اتصال IPv6 که روی روتر پایان می‌یابد هیچ چیزی دربارهٔ اتصال IPv4 که قاعده‌ای کهنه هدایتش می‌کند نمی‌گوید. گزارش سرویس گیرنده را بخوانید تا ببینید کدام نقطهٔ پایانی پاسخ داده است، و پیام موفقیت مشتری را شواهدی ضعیف بدانید. برای آزمایشی معنادار جریان تازه لازم است. از میزبان بیرونی با nc -zvu 203.0.113.7 1194 کاوشگر بفرستید و گزارش برنده را با journalctl -u openvpn@server -n 20 بخوانید. شنوندهٔ روتر خودِ اتصال را ثبت می‌کند، در حالی که میزبان شبکهٔ محلی آن را در سرویس خودش ثبت می‌کند.

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

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