مهاجرت از یک VPN مبتنی بر PPP بدون کپی کردن فرض‌های آن
ابتدا هویت‌ها، استخرهای نشانی، مسیرها، DNS و سیاست دسترسی را فهرست کنید. یک دست‌دادن کارساز به معنای مهاجرتی نیست که همان مرز دسترسی را حفظ کرده باشد.
مهاجرت VPN زمانی تمام می‌شود که کاربران، مقصدها، حل نام و رفتار در برابر خرابی هنوز درست باشند، نه وقتی کارخواه جدید نماد سبزی نشان می‌دهد. استقرارهای قدیمی مبتنی بر PPP فرض‌هایی را با خود دارند که هرگز نوشته نشدند: یک راز مشترک که تنها بررسی هویت هم بود، یک استخر نشانی ثابت که دیوار آتش آن را در فهرست مجاز دارد، و یک پسوند DNS که کارساز می‌فرستد. جایگزینی پروتکل بدون فهرست‌کردن این فرض‌ها تونلی می‌سازد که دست‌دادن را کامل می‌کند و مرزی که وجود ندارد. مسیر زیر همان ترتیبی است که من به کار می‌برم، و گام آخر همان گامی است که تیم‌ها از آن می‌گذرند.
گام 1: فهرست کنید اتصال قدیمی چه چیزی فراهم می‌کند
فهرست نوشته می‌شود، نه به خاطر سپرده. کارخواه‌های پشتیبانی‌شده، نقش‌های احراز هویت، استخرهای نشانی، شبکه‌های محافظت‌شده، الزامات DNS و مجوزهای سرویسی را که هر گروه کاربری نیاز دارد ثبت کنید.
برای L2TP/IPsec دو لایه را آشکارا از هم جدا کنید. هویت همتای IPsec ماشین‌ها را احراز می‌کند؛ PPP کاربر را احراز می‌کند، معمولاً با CHAP یا MSCHAPv2.
در همین جداسازی است که استقرارهای قدیمی فرض‌هایشان را پنهان می‌کنند. کلید از پیش اشتراکی که هر کارخواه آن را به اشتراک می‌گذارد یک گروه را احراز می‌کند، نه یک دستگاه، و اغلب تنها چیزی است که هرگز چرخش داده شده. اگر حساب PPP همان کنترل واقعی هر کاربر است، بگویید، زیرا جایگزین باید آن کنترل را با چیزی بازتولید کند که رشته مشترک نیست. نشانی‌های مبدأ ثابت و استثناهای شبکه محلی را هم یادداشت کنید، چون این‌ها همان وابستگی‌هایی هستند که هیچ‌کس تا وقتی نشکنند مستند نمی‌کند.
گام 2: جایگزین را آگاهانه طراحی کنید
انتخاب جایگزین نگاشت نیاز به نیاز است: پروتکلی و کارخواهی نگهداری‌شده که سازمان از آن پشتیبانی می‌کند، با هر نیاز هویت و دسترسی که در سازوکاری واقعی فرود می‌آید. راز مشترک به‌طور خودکار معادل کلید یا گواهی هر دستگاه نیست، و حساب PPP هر کاربر معادل گواهی دستگاه نیست.
پیش از هر چیز بازه‌های نشانی را هماهنگ کنید، چون استخر جایگزینی که با یک LAN خانگی یا اداری همپوشانی دارد خرابی‌ای می‌سازد که هیچ ربطی به قدرت رمز ندارد. استخر را با همان فهرستی که برای سرویس قدیمی ساختید بررسی کنید، به‌علاوه آنچه کارخواه جدید به‌طور پیش‌فرض فرض می‌کند. مسیریابی بازگشتی شبکه‌های محافظت‌شده را تأیید کنید و تأیید کنید که کارخواه جدید می‌تواند پسوند DNS را که کارخواه قدیمی می‌فرستاد بفرستد یا مستند کند. همین دو مورد بیش از خود تغییر پروتکل بلیت مهاجرت ایجاد می‌کنند.
گام 3: مرحله‌ای اجرا کنید و هم اجازه و هم رد را بررسی کنید
با یک کاربر نماینده و یک برنامه نماینده اجرا کنید. حل DNS خصوصی را در آزمون بگنجانید، چون تونلی که به نشانی می‌رسد اما نمی‌تواند نام داخلی را حل کند فقط نیمه مهاجرت کرده است. وضعیت در دسترس نبودن مورد انتظار را هم بگنجانید: وقتی تونل می‌افتد چه باید بشود، و آیا کارخواه آن را اعمال می‌کند.
سپس مقصدی را بیازمایید که باید رد بماند. یک قاعده اجازه موقت و گسترده می‌تواند تونل جدید را سالم نشان دهد در حالی که بی‌صدا مرز مجوزی را که سرویس قدیمی اعمال می‌کرد برمی‌دارد، و کسی تا هنگام حسابرسی متوجه نمی‌شود. نتایج اجازه و رد را کنار هم مقایسه کنید، از همان کارخواه، در همان نشست. سرویس قدیمی را تا وقتی هر دو ستون با طراحی جور شوند در حال اجرا نگه دارید.
پیش از جابه‌جایی دسترسی مدیر، تأیید کنید که مسیر بازیابی مجاز دارید که به تونلی که تغییر می‌دهید وابسته نباشد.
گام 4: هویت قدیمی را بازنشسته کنید
بازنشسته‌کردن درست هویت قدیمی یعنی لغو کاربران منسوخ و اعتبارنامه‌های دستگاه از طریق سرویسی که مالک آن‌هاست، سپس حذف نمایه‌ها و شنودگرهای قدیمی وقتی هیچ وابستگی باقی نمانده است. پاک کردن یک پرونده محلی نسخه‌ای در جای دیگر را لغو نمی‌کند، و شنودگر قدیمی که هنوز راز مشترک قدیمی را می‌پذیرد دری بی‌مراقبت است.
این نکته ارزش آن را دارد که آهسته‌تر شویم. نمایه کارخواه از رده خارج‌شده روی یک لپ‌تاپ اعتبارنامه لغوشده نیست؛ اعتبارنامه روی کارساز زندگی می‌کند و تا وقتی کارساز پذیرش آن را متوقف نکند معتبر می‌ماند. نسخه‌های دیگر پیکربندی قدیمی را جست‌وجو کنید — دستگاه‌های آزمایشی، تلفنی فراموش‌شده، نصب‌کننده‌ای که کسی نگه داشته — و خاموش‌کردن شنودگر را لحظه‌ای بدانید که سرویس قدیمی واقعاً پایان می‌یابد. تا آن زمان، مهاجرت دو درِ جلو دارد.
رکورد پذیرش همان فهرست گام یک است با ستونی افزوده: طراحی جدید برای هر ردیف چه می‌کند و شما چگونه آن را بررسی کردید. این کار ارتقای پروتکل را به الزامی سرویسی همراه با شواهد تبدیل می‌کند.
نتیجه را به آنچه سرویس نیاز دارد گره بزنید نه به نام پروتکل، چون پروتکل مدرنی که فرض‌های قدیمی در آن کپی شده باشد همان ریسک با چارچوبی بهتر است. RFC 3193 توصیف می‌کند که L2TP چگونه روی IPsec حمل می‌شود، که یادآور سودمندی است که آن دو لایه همیشه تصمیم‌های جداگانه بودند. اگر در فهرست ردیفی هست که نمی‌توانید توضیح دهید، بایستید و بفهمید چه چیزی به آن وابسته است. مهاجرت وقتی تمام است که فهرست کسل‌کننده شود.