پس از اجرای اسکریپت نصب، کسی باید مالک سرور VPN باشد
اسکریپت میتواند سرور را بسازد، اما نمیتواند سیاست دسترسی، مسیر بهروزرسانی یا بازگردانی را بر عهده بگیرد. پیش از اجرا، تحویل را تعریف کنید.
دو کار متفاوت بهصورت یکی فروخته میشود: تبدیل یک ماشین به سرور VPN، و افزودن یک کلاینت VPN به لپتاپی که باید به دروازه شخص دیگری بپیوندد. اسکریپت نصب به اولی پاسخ میدهد و نمیتواند به دومی پاسخ دهد، هر چه README آن القا کند. پروژه setup-ipsec-vpn را نمونهای مشخص بگیرید: سروری با IPsec/L2TP، Cisco IPsec یا IKEv2 روی میزبان لینوکس پشتیبانیشده با Libreswan و xl2tpd میسازد. این یک قرارداد استقرار برای سرور است، نه دستور کلی برای هر ماشینی. پیش از اجرای اسکریپت تصمیم بگیرید کدام کار را دارید، چون همه چیز پس از آن درباره سرور است.
درباره میزبان صادق باشید
ماشینی که چیز دیگری را هم پایان میدهد، یا دیوار آتش آن بهجای سیستمعامل توسط یک صفحه کنترل ابری مدیریت میشود، نصب متفاوتی از یک ماشین مجازی تمیز است. پروتکلی را که فعال میکنید و نسخهای را که به کار میبرید بنویسید، سپس هر دو را با فهرست پشتیبانی پروژه بسنجید، نه با یک نوشته وبلاگی از سال گذشته.
فعال کردن سرویس راه را به آن باز نمیکند. برای IPsec، شبکه پیش از میزبان باید UDP 500 و 4500 را بپذیرد و بسته به استقرار، خود پروتکل ESP را. اسکریپتی که پشت گروه امنیتی که پروتکل 50 را دور میریزد با موفقیت تمام میشود، سروری ساخته که هیچکس به آن نمیرسد، و هیچ چیز در خروجی نصبکننده این را نمیگوید.
نصبکننده واقعاً چه چیزی را بر عهده میگیرد
انتظار فایل پیکربندی و اسرار IPsec، پیکربندی دیمن L2TP، گزینههای PPP و واحدهای systemd را داشته باشید که اکنون مالک آن پورتها هستند. README پروژه میگوید فایلهای پیکربندی موجود پیش از تغییرات پشتیبانگیری میشوند، که مفید است و همانند پشتیبان کل میزبان نیست. تعیین کنید کدام اجزا با بستههای توزیع و کدام با اجرای دوباره یا بازنویسی اسکریپت بهروزرسانی میشوند، چون اینها دو مسیر نگهداری با حالتهای خرابی متفاوتاند.
نسخهای را که تأیید کردید ثابت کنید. نشانی دانلودی که شاخه پیشفرض جاری را ارائه میدهد ممکن است ماه بعد محتوای دیگری برگرداند، پس commit یا نسخهای را که اجرا کردید ثبت کنید و کپی آن را نگه دارید. همین یک عادت، وضعیت غیرقابلانتساب را به چیزی تبدیل میکند که شخص دومی بتواند ساعت دو بامداد دربارهاش فکر کند.
آنچه اسکریپت نمیتواند به شما بدهد
اتوماسیون نصبی کارآمد میسازد و همانجا میایستد. تصمیم نمیگیرد تونل باید به کدام منابع خصوصی برسد، که پرسشی درباره سیاست دسترسی است و هم دیوار آتش میزبان و هم شبکه بالادست دربارهاش نظر دارند. تصمیم نمیگیرد چه کسی اعتبارنامه میگیرد، چگونه تحویل میشود، یا دسترسی کسی هنگام رفتن چگونه حذف میشود. و تصمیم نمیگیرد چگونه ماشین بازیابی میشود پس از یک بهروزرسانی بد، که همان بخشی است که معمولاً در بدترین لحظه کشف میشود.
پروفایلهای کلاینت و اسرار نمایشدادهشده مواد دسترسیاند، نه گزارش نصب. پروفایل تولیدشدهای که در کانالی مشترک گذاشته شود یک حساب است، و همان استاندارد برای تصاویر خلاصه نصب هم صادق است. فهرست محافظتشدهای از وضعیت هویتی که برای بازگرداندن سرویس لازم است نگه دارید و یادداشت کنید کدامیک از این اعتبارنامهها از آن پس باطل شدهاند.
نخستین کلاینت آزمون پذیرش است
استقرار را از یک کلاینت مجاز بپذیرید، با پروتکلی که واقعاً فعال کردید. بررسی کنید که نام خصوصی حل میشود، مسیر بازگشت کار میکند، اتصال دوباره درست رفتار میکند و مقصدی بیرون از مجموعه مجاز رد میشود. ورود موفق از یک برنامه کلاینت دیگر شاهدی بر برنامهای که فرستادید نیست.
اگر ترکیبی که میخواهید دیگر پشتیبانی نمیشود، پیش از نصب مسیری نگهداریشده انتخاب کنید. زنده کردن نسخهای قدیمی، تضعیف احراز هویت یا اجرای دوباره اسکریپتی توضیحنشده به تعویق انداختن است، نه برنامه نگهداری، و هر یک تحویل را سختتر میکند.
صفحه تحویل را بنویسید
کوتاه نگه دارید: سرور، نسخهای که آن را ساخته، پورتهای لازم، اجزا و مالکان بهروزرسانیشان، منابع مجاز، مسیر اعتبارنامه و رویه بازیابی. مسیر کنسول یا خارج از باند را که هنگام خراب شدن دسترسی با تغییر تونل به کار میبرید بیفزایید. آنگاه شخص بعدی سرویسی را به ارث میبرد، نه فرمانی را که از اجرای دوبارهاش میترسد.
هر بار که میزبان تغییر میکند آن صفحه را بازبینی کنید، نه فقط وقتی چیزی خراب میشود. سند تحویلی که هرگز خوانده نمیشود سندی است که بیصدا از درست بودن بازمانده است.