دروازه VPN ترکیبی یا جداگانه: بر اساس دامنه خرابی انتخاب کنید

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

چه چیزی در یک راه‌اندازی مجدد متوقف می‌شود

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

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

مالکیت نگهداری را هم بشمارید. دستگاه دیگر پیکربندی، پایش، پشتیبان‌گیری و رویه بازیابی دوم می‌آورد و هیچ‌یک از این‌ها رایگان نیست.

علامت بزنید هر قاعده کجا اعمال می‌شود

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

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

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

اگر نمی‌توانید بگویید کدام دستگاه قاعده مهم را اعمال می‌کند، متوقف شوید. همان شکاف یافته است، نه جزئیاتی که بعداً حل شود.

مهار مرز است، نه شاسی

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

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

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

آنچه را واقعاً می‌توانید برسید بازیابی کنید

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

systemctl status strongswan
nft list ruleset
ip -brief address

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

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