آیا برای سرور VPN خانگی به DNS دینامیک نیاز دارید؟

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

شرط یکم: نشانی شما واقعاً جابه‌جا می‌شود

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

اندازه بگیرید نه حدس بزنید. نشانی WAN را در صفحه وضعیت روتر بخوانید و آن را با آنچه دنیای بیرون می‌بیند مقایسه کنید. این را از ماشینی در LAN اجرا کنید:

curl -fsS https://api.ipify.org; echo

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

شرط دوم: کلاینت‌ها دوباره نام را جست‌وجو می‌کنند

TTL کوتاه همان بخشی است که مردم از آن می‌گذرند. حل‌کننده‌های بازگشتی به TTL رکورد احترام می‌گذارند، اما پشته‌های کلاینت جداگانه کش می‌کنند و تونلی که از قبل برپاست چیزی را دوباره حل نمی‌کند. هنگام اشکال‌زدایی رکورد را روی 60-300 ثانیه بگذارید؛ این پنجره‌ای را که پاسخ کهنه سرو می‌شود کوتاه می‌کند و نشست متصل را منتقل نمی‌کند.

OpenVPN هر بار که دوباره وصل می‌شود خط remote vpn.example.net 1194 را از نو حل می‌کند، و resolv-retry infinite آن را به تلاش دوباره وامی‌دارد به‌جای خروج وقتی جست‌وجو شکست می‌خورد. روی سرور، float اجازه می‌دهد نشست برپاشده همتایی را دنبال کند که نشانی مبدأش تغییر کرده است. WireGuard روراست‌تر است: wg-quick up هنگام اعمال پیکربندی Endpoint را حل می‌کند، و کلاینت هنگام بازسازی تونل آن را دوباره حل می‌کند، پس دست‌دهی‌ای که هنوز در برابر نشانی قدیمی موفق می‌شود تا وقتی متوقف شود موفق می‌ماند.

این تفاوت برنامه را شکل می‌دهد. اگر کلاینت‌ها بر اساس تقاضا وصل شوند، تغییر نشانی یک اتصال دوباره هزینه دارد. اگر نشست را روزها باز نگه دارند، انتظار داشته باشید تونل در دست‌دهی بعدی بمیرد، و کلاینت را به تلاش دوباره وادار کنید نه اینکه فرض کنید بالا می‌ماند.

شرط سوم: مسیر ورود هنوز باز است

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

از بیرون آزمایش کنید. گوشی روی داده همراه با Wi-Fi خاموش ارزان‌ترین آزمون صادقانه است؛ لپ‌تاپ در همان LAN نه. وقتی نام به نشانی عمومی شما حل می‌شود و روتر بازگشت NAT ندارد، آزمون داخلی شکست می‌خورد در حالی که رکورد کاملاً درست است، و همین بیشتر مردم را به ویرایش رکوردی می‌فرستد که هرگز غلط نبوده.

وقتی هر سه برقرارند چه اجرا کنید

ddclient کم‌غافلگیرکننده‌ترین به‌روزرسان برای یک میزبان کوچک است. پیکربندی کمینه نشانی‌ای را منتشر می‌کند که ارائه‌دهنده می‌بیند، و این اشتباه NAT دوگانه را دور می‌زند:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

آن را از یک زمان‌سنج systemd هر چند دقیقه اجرا کنید نه از حلقه shell، و پاسخ ارائه‌دهنده را ثبت کنید نه اینکه موفقیت را فرض کنید. با اعتبارنامه مثل کلید رفتار کنید، چون تعیین می‌کند هر کلاینت به کجا فرستاده می‌شود: از توکن به‌روزرسانی محدود به‌جای گذرواژه حساب استفاده کنید، فایل را روی حالت 0600 نگه دارید و به‌روزرسانی‌ها را روی HTTPS بفرستید.

پیش از تعهد بررسی کنید

یک جست‌وجو به شما می‌گوید بقیه جهان چه می‌بیند، و TTL‌ای را چاپ می‌کند که پس از تغییر باید صبر کنید:

dig +noall +answer vpn.example.net @1.1.1.1

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

یک بازگردانی یک‌دقیقه‌ای نگه دارید: آخرین نشانی کارآمد و TTL پیشین را یادداشت کنید تا هنگام بدبیاری ارائه‌دهنده هر دو را دستی منتشر کنید.

وقتی پاسخ نه است

اگر شرط یکم یا سوم شکست بخورد، تصمیم تغییر می‌کند نه پیکربندی. پشت NAT اپراتور، گزینه‌های عملی شما درخواست نشانی عمومی از ISP، جابه‌جا کردن نقطه ورود به یک VPS کوچک با نشانی پایدار، یا استفاده از لایه‌ای است که ملاقات خودش را نگه می‌دارد. اگر نشانی ثابت است، به‌روزرسان را کنار بگذارید: یک رکورد A، یک رکورد AAAA اگر IPv6 دارید، همان پورت‌فوروارد.

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

پیش از رفتن، چهار چیز را به ترتیب تأیید کنید:

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

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