VPN جابه‌جا شد: چرا کلاینت OpenVPN شما همچنان IP قدیمی را می‌گیرد

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

ببینید پروفایل چه چیزی را می‌گیرد، نه آنچه DNS می‌گوید

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

سپس بررسی کنید آیا پروفایلی که ویرایش کردید همانی است که کلاینت بارگذاری کرده. پروفایل‌های واردشده رایج‌اند: ممکن است مدیری ماه‌ها پیش نسخه‌ای گرفته و نسخه خودش را نگه داشته باشد، پس فایل در پوشه دانلود شما و ورودی در برنامه می‌توانند متفاوت باشند. پیش از هر اشکال‌زدایی DNS، نقطه پایانی را در جزئیات اتصال خود کلاینت مقایسه کنید.

دو فایل، یک نقطه پایانی — یافته معمول اینجا همین است.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

تلاش بعدی کلاینت برای اتصال را بخوانید

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

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

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

بدانید کدام راه‌اندازی مجدد را انجام می‌دهید

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

تنظیمات پایداری هم مهم‌اند، چون برای نگه‌داشتن چیزی طراحی شده‌اند که احراز هویت شده، نه برای دنبال کردن نشانی‌های جدید.

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

چهار گزینه و وظایف جداگانه‌شان

remote با نام میزبان همان تنظیمی است که حل دوباره را اصلاً ممکن می‌کند؛ نشانی تحت‌اللفظی در آن خط آن را منتفی می‌کند. resolv-retry کنترل می‌کند وقتی جست‌وجو شکست می‌خورد چه می‌شود و نسخه 2.6 آن را از پیش به بی‌نهایت تنظیم می‌کند. پس افزودن آن چیزی را تغییر نمی‌دهد و هرگز بررسی دوره‌ای برای پاسخ متفاوت زمان‌بندی نمی‌کند. هر کس بگوید برای نشانی‌های جدید نظرسنجی می‌کند، بازیابی را با تازگی اشتباه گرفته است.

persist-remote-ip درباره پیوستگی است، نه تازگی: نقطه پایانی را که آخرین بار احراز هویت کرد، در راه‌اندازی‌های مجدد نرمی که پشتیبانی می‌کند دوباره به کار می‌برد. وقتی جابه‌جایی را آزمایش می‌کنید، این خلاف چیزی است که می‌خواهید. اگر ساخت شما آن را فعال می‌کند، برای آزمایش خاموشش کنید و پس از اثبات نقطه پایانی جدید دوباره روشن کنید. اگر روشن بماند، اتصال دوباره موفق ممکن است هیچ چیزی درباره DNS به شما نگوید.

float همتایی احراز هویت‌شده را می‌پذیرد که نشانی‌اش میان نشست تغییر کرده، و فقط در آرایش‌هایی که از آن پشتیبانی می‌کنند. DNS را تازه نمی‌کند و به‌خودی‌خود تغییر ارائه‌دهنده را دنبال نخواهد کرد. آن را ویژگی تاب‌آوری برای همتایان سیار بدانید، نه سازوکار نشانی پویا برای سرورها.

پیش از سرزنش کلاینت، نقطه پایانی جدید را تأیید کنید

از بیرون شبکه خود بررسی کنید که نشانی جدید شنونده‌ای روی پورت پیکربندی‌شده دارد و هدایت ارائه‌دهنده به آن اشاره می‌کند. رکورد A درست برای ماشینی بدون پورت باز، دقیقاً همان نشانه‌ای را می‌سازد که مردم به حافظه نهان نسبت می‌دهند.

سپس دوباره متصل شوید و دو چیز را تأیید کنید: کلاینت در برابر گواهی سرور مورد انتظار احراز هویت کرده و نشست به منبعی که در نظر داشتید می‌رسد. تغییر نشانی الزامات هویت را پایین نمی‌آورد و اتصالی که به نقطه پایانی اشتباه موفق شود بدتر از اتصالی است که شکست می‌خورد. راهنمای OpenVPN 2.6 هر چهار گزینه را با حوزه خودشان فهرست می‌کند و همان چک‌لیستی است که باید کنار پروفایل نگه دارید.

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