چرا سرور VPN پشت CGNAT هرگز اتصالی را نمی‌پذیرد

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

تأیید نشانی مشترک دو دقیقه وقت می‌گیرد و از یک هفته تغییر پیکربندی جلوگیری می‌کند.

نشانه‌هایی که به NAT اپراتور اشاره می‌کنند

نشانی WAN در صفحه وضعیت روتر را با نشانی‌ای که یک جستجوی بیرونی گزارش می‌کند مقایسه کنید. نشانی WAN در محدوده 100.64.0.0/10 نشانه معمول است، و محدوده‌های خصوصی 10/8، 172.16/12 و 192.168/16 همان معنا را دارند. اگر traceroute همان پرش عمومی را تکراری نشان دهد، یا یک پرش اولیه با نشانی خصوصی پاسخ دهد، مترجم دیگری بین روتر و اینترنت نشسته است. برخی ISPها نشانی تخصیص‌یافته را فقط در پرتال مشتری فهرست می‌کنند، پس آن مقدار را همراه با traceroute خروجی بگیرید.

تغییر پروتکل‌ها یا پورت‌ها کمکی نمی‌کند، چون مشکل دسترسی‌پذیری ورودی است نه پورت بسته.

چرا ارسال پورت و DNS پویا نمی‌توانند آن را درست کنند

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

پیکربندی مجدد مشتری هم کمکی نمی‌کند، چون شکست پیش از خوانده شدن هر تنظیم مشتری رخ می‌دهد.

رله از طریق VPS با مسیرهای صریح

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

روی VPS یک ورودی دایرکتوری مخصوص مشتری اضافه کنید تا سرور بداند کدام همتا مالک زیرشبکه خانه است، و یک مسیر هسته مطابق اضافه کنید.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

خط iroute به OpenVPN می‌گوید کدام مشتری ترافیک زیرشبکه خانه را دریافت می‌کند؛ خط route آن زیرشبکه را در جدول هسته VPS قرار می‌دهد تا بسته‌ها اصلاً وارد تونل شوند. برای سرویس منتشرشده، یک قاعده NAT مقصد اضافه کنید که پورت عمومی را به 10.8.0.10 ارسال کند و net.ipv4.ip_forward را فعال کنید.

مسیر را از بیرون آزمایش کنید

هر پرش را در طرف عمومی بررسی کنید، چون تونل موفق ثابت نمی‌کند که سرویس قابل دسترس است. وضعیت گوش دادن و ضبط بسته روی VPS بین «چیزی نرسید» و «رسید و دور ریخته شد» تفکیک می‌کند.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

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

گزینه‌هایی که ارزش دارد اول قیمت‌گذاری شوند

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

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