روتر تازه، همان سرور VPN: ورودی عمومی آن را جابه‌جا کنید

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

تعویض را دو تحویل بدانید نه یکی، و در طول کار یک راه محلی به رابط مدیریت نگه دارید.

پیش از جدا کردن کابل، تحویل را بنویسید

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

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

آن سابقه را جایی محافظت‌شده نگه دارید. نسخه پشتیبان روتر می‌تواند اعتبارنامه پیوند WAN را در خود داشته باشد. با فایل صادرشده مثل گذرواژه رفتار کنید نه مثل یادداشت تنظیمات.

اول نشانی را جابه‌جا کنید، بعد ارسال را

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

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

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

تصمیم بگیرید چه کسی نام عمومی را به‌روز می‌کند

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

وقتی استقرار هر دو خانواده نشانی را منتشر می‌کند، هم رکورد A را بخوانید و هم AAAA را. هر یک باید به سرویسی اشاره کند که واقعاً گوش می‌دهد و از مسیر دیوار آتش خودش مجاز است، و نگاشت IPv4 کارآمد چیزی درباره سمت IPv6 نمی‌گوید. بازبینی‌های هویت را هم در نمایه کلاینت نگه دارید: نشانی عمومی تغییریافته دلیلی برای پذیرفتن گواهی یا کلید همتایی که نمی‌خواند نیست.

تعویض را از بیرون اثبات کنید

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

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

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

نگاشت تازه را کنار یادداشت‌های بازیابی نگه دارید

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

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