آیا فکر می‌کنید تغییر نام سرور Pritunl نقطه پایانی آن را عوض می‌کند؟

تغییر نام یک سرور Pritunl یک برچسب در کنسول را عوض می‌کند. این کار نشانی‌ای را که پروفایل‌های کلاینت به آن وصل می‌شوند عوض نمی‌کند و رکورد DNS هم نمی‌سازد. مقداری که اهمیت دارد نشانی عمومی میزبان است و نام را به همان سادگی یک نشانی می‌پذیرد.

نامی که کلاینت‌ها به آن وصل می‌شوند در یک فیلد میزبان زندگی می‌کند

Pritunl نقطه پایانی را از طریق تنظیم نشانی عمومی میزبان ارائه می‌دهد که یا یک نشانی IP عمومی یا یک نام DNS را می‌پذیرد. vpn.example.net را آنجا بگذارید تا پروفایل‌های تولیدشده و همگام‌سازی احراز‌شده آن نام را به کلاینت‌ها تحویل دهند. رکورد باید از قبل وجود داشته باشد و به شنونده‌ای که انتقال VPN را می‌پذیرد تفکیک شود؛ این فیلد یک مقصد را اعلام می‌کند، آن را منتشر نمی‌کند. نام نمایشی یک شیء سرور فراداده اداری است و هرگز به تلاش اتصال کلاینت نمی‌رسد.

پس نخستین گام تغییر نام هیچ چیز نیست. تنظیمات میزبان را باز کنید، نشانی عمومی را عوض کنید و از طریق رابط پشتیبانی‌شده ذخیره کنید.

سه فیلد که شبیه هم به نظر می‌رسند و نیستند

نشانی محلی به تکثیر و مسیریابی میان میزبان‌های Pritunl خدمت می‌کند. نشانی پیوند توصیف می‌کند که سرورهای پیوندشده چگونه به هم می‌رسند. هیچ‌کدام نشانی‌ای نیست که کلاینت به آن وصل می‌شود و کپی کردن نام عمومی در آن‌ها توپولوژی‌ای را که توصیف می‌کنند می‌شکند. نشانی IPv6 عمومی فیلدی جداگانه با رکورد و مسیر خودش است؛ یک رکورد A برای IPv4 دسترسی‌پذیری IPv6 را برقرار نمی‌کند.

یک نام DNS نیز هیچ نگاشت پورتی و هیچ شنونده‌ای با خود ندارد. اگر سرویس روی 1194 UDP گوش می‌دهد، نام همچنان به میزبانی تفکیک می‌شود که باید 1194 UDP را بپذیرد. یک پروکسی معکوس HTTP روی پورت 443 که کنسول وب را سرویس می‌دهد نقطه پایانی انتقال VPN نیست، حتی وقتی هر دو نام یکسان را شریک‌اند.

مسیریابی مبتنی بر دامنه در داخل تونل لایه‌ای دیگر است. نام‌گذاری نقطه پایانی بیرونی هیچ چیزی درباره مقصدهای خصوصی‌ای که کلاینت می‌تواند برسد نمی‌گوید.

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

تغییر فیلد پروفایل‌هایی را که پیش‌تر سرور را ترک کرده‌اند بازنویسی نمی‌کند. همگام‌سازی پیکربندی احراز‌شده Pritunl می‌تواند تغییرات نشانی و پورت میزبان را به کلاینت‌های سازگار برساند و کلاینت CLI مستند پیش از اتصال یا اتصال دوباره همگام‌سازی می‌کند. پروفایلی که در NetworkManager یا یک کلاینت مستقل OpenVPN وارد شده کانال چنین چیزی ندارد و به جایگزین تأییدشده نیاز دارد. نشست‌های موجود چیزی را اثبات نمی‌کنند، چون با مقدار قدیمی برقرار شده‌اند.

وقتی کنسول وب پشت یک متعادل‌کننده بار قرار دارد، Pritunl تنظیم جداگانه نشانی همگام‌سازی را برای مسیر همگام‌سازی مستند می‌کند. نام میزبان کنسول را فقط به این دلیل که هر دو Pritunl هستند برای شنونده VPN دوباره به کار نبرید.

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

تغییر را با یک اتصال واقعی بپذیرید

تفکیک ضعیف‌ترین آزمون ممکن است. dig +short vpn.example.net که نشانی برمی‌گرداند فقط ثابت می‌کند رکوردی وجود دارد.

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

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