راهنمای اجرا: پذیرش جداگانه دو مشتری OpenVPN

دو مشتری روی یک میزبان شبیه یک بلوک سرور اضافه و یک پورت دوم به نظر می‌رسد. اما وقتی همه چیزهایی را که یک مشتری واقعاً در اختیار دارد فهرست کنید، به پروژه‌ای دیگر تبدیل می‌شود: یک شنونده، یک استخر تونل، یک هویت، فایل‌های اعتماد، مسیرها و یک برنامهٔ ابطال. اگر یکی از آن‌ها را جا بیندازید، مشتری دوم بی‌صدا بخشی از اولی را به ارث می‌برد. برای هر مشتری یک کارت بسازید و آن را پیش از اتصال اولین مشتری پر کنید.

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

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

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

مواد اعتماد را درون هر مشتری نگه دارید

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

کلید خصوصی خود سرور به یک فایل محافظت‌شده برای هر مشتری تعلق دارد، نه به پوشهٔ قالبی که همراه پیکربندی تکثیر می‌شود.

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

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

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

بررسی شنونده نشان می‌دهد کدام فرایند مالک هر پورت عمومی است، و تأیید نشان می‌دهد آیا گواهی مشتری به لنگر موردنظر زنجیره می‌شود. هیچ‌یک از این دو خروجی اثبات نمی‌کند که مشتری A نمی‌تواند به زیرشبکهٔ B برسد، پس سیاست مبدأ و مقصد، مسیرهای بازگشت و هر سرویس عمداً مشترک را تعریف کنید. فضاهای نام شبکه یا کانتینرها زمینه‌های مسیریابی را جدا می‌کنند و آمیختگی تصادفی را کم می‌کنند، اما آن‌ها یک مرز کامل مستأجر نیستند به‌تنهایی. وقتی مدل تهدید ایجاب می‌کند مکانیزم جداسازی قوی‌تری انتخاب کنید.

ابطال را پیش از تحویل برسانید

استقرار گواهی کامل نیست تا وقتی ابطال مسیر تحویل داشته باشد. صادرکننده و پنجرهٔ اعتبار CRL را به‌عنوان بخشی از پذیرش بررسی کنید.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

بازرسی CRL گزارش می‌دهد فهرست چه زمانی صادر شده و چه زمانی منقضی می‌شود، و وضعیت سرویس تأیید می‌کند نمونه‌ای که آن را می‌خواند در حال اجراست. فهرست را طبق برنامهٔ سیاست صدور تازه کنید حتی وقتی چیز جدیدی ابطال نشده، زیرا CRL منقضی می‌تواند هر مشتری را رد کند. به‌جای اینکه خوانندگان با نوشتن ناقص روبه‌رو شوند یک فایل کامل منتشر کنید، و امضا را پیش از استقرار اعتبارسنجی کنید. ثبت کنید مالکیت صدور، بهره‌برداری از نقطهٔ پایانی و بازنشستگی با کیست، تا خاموش کردن مشتری A به B آسیب نزند.

سپس جفت پذیرش را اجرا کنید: مشتری مجاز به سرویس خودش می‌رسد و اعتبارنامهٔ A توسط شنوندهٔ B رد می‌شود. این همان مرز است که به‌صورت آزمون بیان شده است.