پس از رمزگشایی: کدام سیاست ترافیک VPN شما را اول میبیند
کابل چیزی درباره این که کدام قاعده جریان را پردازش کرده نمیگوید. قلاب سیاست و گام بعدی را نام ببرید، سپس ثابت کنید پاسخ از همان مسیر میگذرد.
یک جریان VPN میتواند کاملاً رمزگذاری و کاملاً احراز هویت شده باشد و باز هم جایی فرود بیاید که هیچکس برنامهریزی نکرده است. کابلی که وصل میکنید تعیین نمیکند کدام قاعده بسته درونی را پردازش میکند؛ قلاب سیاست و مسیر این کار را میکنند. بنابراین دو طرح که روی نمودار رک یکسان به نظر میرسند میتوانند اجرای کاملاً متفاوتی داشته باشند. انتخاب میان آنها با نام بردن کنترلی آغاز میشود که جریان رمزگشاییشده را اول میبیند.
بر اساس قلاب سیاست تصمیم بگیرید، نه پورتی که به آن وصل میشوید
هر بستر VPN ترافیک رمزگشاییشده را در نقطهای پیش از ارسال ارزیابی میکند، و آن نقطه در پیکربندی نامی دارد. روی یک بستر فیلتر سیاست گروهی است، روی دیگری سیاست رابط یا جفت ناحیه، و روی دستگاهی که مسیریابی میکند ممکن است فقط زنجیره forward باشد. قلاب همان چیزی است که قاعده را اجرا میکند، در حالی که پورت سوئیچ تنها جایی است که کابل تمام میشود. یافتن قلاب نخستین تصمیم است، چون هر چیز دیگر جایگذاری نسبت به آن است.
پیش از نگاه به سختافزار، جریان را بنویسید: منبع کیست، به کجا میرود، کدام پروتکل آن را میبرد و کدام سرویس مجاز است. سپس کنترلی را بیابید که هر یک از این چهار واقعیت را اجرا میکند.
دو مسیر، دو روایت متفاوت از اجرا
دو شکل رایج است و هر یک میتواند برای نیاز متفاوتی درست باشد.
endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnetشکل اول میتواند همه چیز لازم را روی دروازه اجرا کند، به شرط آن که سیاست دروازه برای آن مقصد نوشته شده باشد و سرور راهی برای دور زدن آن نداشته باشد. شکل دوم یک مرز اضافه میکند، اما تنها اگر مسیرها و سیاست واقعاً ترافیک را از آن عبور دهند. سروری که در همان قطعه نقطه پایانی است ممکن است هرگز گام میانی خیالی را دنبال نکند. نمودار قصد را نشان میدهد و جدول مسیریابی نشان میدهد چه رخ میدهد.
با جستجوی مسیر بررسی کنید، نه با نقشه. رابطی که بسته از آن خارج میشود و گام بعدی که انتخاب میکند تعیین میکنند شکل دوم همانگونه که طراحی شده رفتار میکند یا نه.
ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20توپولوژی را از انزوا جدا کنید
اشتراک یک زیرشبکه جایی را غیرقابل اعتماد نمیکند و ترانزیت اختصاصی آن را محافظتشده نمیسازد. آنچه تعیین میکند محدودیت واقعاً اعمالشده، ارسال واقعی و این است که هر بخش را چه کسی اداره میکند. شمردن سوئیچها هیچ چیزی درباره هیچیک از این سه نمیگوید. از سیاست و مسیر تصمیم بگیرید و بگذارید توپولوژی از تصمیم پیروی کند.
جمعیتهای ترافیک را هم جدا نگه دارید. استخرهای دسترسی راه دور، پیشوندهای سایت به سایت و شبکههای خط اختصاصی میتوانند یک دستگاه را شریک شوند و باز هم قواعد متفاوت بخواهند، چون هویت و ریسکشان متفاوت است. قاعدهای که برای یک جمعیت نوشته شده، وقتی طرح نشانی مشترک است، بقیه را بیصدا پوشش میدهد.
شکست و مدیریت را برای هر جایگاه بررسی کنید
هر جایگاه یک حالت شکست دارد و پرسش سودمند این است که وقتی یک جزء میایستد چه چیزی هنوز کار میکند. چند رابط منطقی روی یک دستگاه مرده بازیابی مستقل به شما نمیدهد و دیوار آتش پاییندستی که همان تغذیه یا همان مدیر را شریک است مرز دوم نیست. بپرسید مسیر مدیریت از کجا میگذرد، چون کنسولی که فقط از طریق تونل در دسترس است هیچ مسیر بازیابی نیست؛ ssh [email protected] true از بیرون تونل ارزانترین راه اثبات این است که کنسول به آن وابسته نیست. مستندات سیاست گروهی یک بستر فیلتر خود را روی ترافیک پس از رمزگشایی و پیش از رمزگذاری میگذارد، که دقیقاً همان قلاب نامدار است که باید در هر محصولی جستوجو شود.
روایت شکست هر نامزد را کنار روایت اجرا بنویسید. جایگاهی که در بازرسی برنده و در بازیابی بازنده است یک معامله است و باید همینگونه ثبت شود، نه آن که در میانه یک رخداد کشف شود.
با یک جریان مجاز و یک جریان ردشده بپذیرید
با طرح آزمون تأییدشده، سه چیز را از منبع واقعی VPN بررسی کنید: برنامهای که باید کار کند، منبعی که نباید، و جهتی که پاسخ از آن بازمیگردد. رد شدن شاهدی است بر این که سیاست درگیر است، در حالی که جریان مجاز فقط وجود یک مسیر را ثابت میکند.
مسیر انتخابشده و نتیجه سیاست را با هم نگه دارید، چون نتیجهای بدون مسیر بازتولیدشدنی نیست و مسیری بدون نتیجه قابل دفاع نیست. این جفت برای انتخاب نقطه اتصال بسیار سودمندتر از هر ادعایی درباره این است که کدام لایه سوئیچینگ بهطور ذاتی ایمنتر است.