قواعد AWS Client VPN به منبع تعلق دارند، نه به زیرشبکه
یک زیرشبکه دوم هیچ پورتی را محدود نمی‌کند. قاعده را روی گروه امنیتی منبع بگذارید و از گروه انجمن نقطه پایانی به عنوان منبع استفاده کنید.
کارکنان باید به یک برنامه در VPC دسترسی پیدا کنند و نباید به شنونده پایگاه داده روی همان نمونه برسند، بنابراین کسی یک زیرشبکه عمومی دوم برای نقطه پایانی VPN اضافه می‌کند و الزام را برآورده‌شده می‌داند. جای زیرشبکه مسیریابی و دسترس‌پذیری را تغییر می‌دهد. اما یک پورت هم نمی‌دهد و نمی‌گیرد. اجازه‌ای که الزام را بیان می‌کند در مقصد، در گروه امنیتی منبع، زندگی می‌کند و مرز VPN دستگیره‌ای را فراهم می‌کند که آن قاعده به آن اشاره دارد.
جای زیرشبکه مسیریابی است، نه مجوزدهی
اینکه انجمن شبکه نقطه پایانی کجا قرار دارد تعیین می‌کند کدام جدول مسیر ترافیک کارخواه را حمل می‌کند و کدام مناطق دسترس‌پذیری از یک خرابی جان سالم به در می‌برند. اما هیچ نمی‌گوید که این ترافیک می‌تواند به کدام پورت روی کدام نمونه برسد. دو کارخواه مرتبط با همان زیرشبکه هنوز با همان هویت منبع می‌رسند و منبع نمی‌تواند آن‌ها را با نام زیرشبکه از هم تشخیص دهد.
در عوض از الزام شروع کنید: چه کسی فراخوانی می‌کند، کدام منبع، کدام پورت سرویس و کدام جهت. سپس مدل قاعده‌ای را انتخاب کنید که می‌تواند آن چهار چیز را در مقصد بیان کند. این چارچوب معمولاً زیرشبکه اضافی را کاملاً از طراحی حذف می‌کند.
گروه انجمن Client VPN همان دستگیره است
برای نقطه پایانی AWS Client VPN مرتبط با زیرشبکه، ترتیب مستند مشخص است. گروه امنیتی مورد نظر را روی انجمن‌های شبکه هدف نقطه پایانی اعمال کنید، سپس ترافیک لازم را در گروه امنیتی منبع با استفاده از همان گروه Client VPN به عنوان منبع مجاز کنید.
به طور مشخص، گروه نمونه برنامه فقط پورت برنامه را از گروه انجمن مجاز می‌کند و نه چیز دیگری. رویه دسترسی به منبع در AWS این رابطه را توصیف می‌کند و ارزش دارد که همان سیاست گروه در هر زیرشبکه‌ای که نقطه پایانی به آن مرتبط می‌شود حفظ شود، زیرا یک انجمن قدیمی با گروهی متفاوت مرز را بی‌سروصدا گسترده می‌کند.
آن قاعده هیچ‌کس را احراز هویت نمی‌کند. ورود یک کنترل جداگانه است و مسیر رسیدن به منبع سومی است. هر سه باید برقرار باشند تا درخواستی برسد. هر کدام که شکست بخورد تعیین می‌کند کدام اصلاح درست است و تغییر قاعده فقط برای اولی پاسخ درست است.
چیزی که یک گروه انجمن نمی‌تواند از هم تشخیص دهد
هر کارخواه پشت همان گروه انجمن به عنوان همان منبع گروه امنیتی به منبع می‌رسد. دو کاربر با نقش‌های متفاوت در آن لایه قابل تفکیک نیستند، هر نام و برچسبی که گروه داشته باشد. مجوزدهی گروه‌های بیرونی Client VPN دسترسی را بر اساس پیشوند مقصد برای یک گروه دایرکتوری یا SAML محدود می‌کند که از نقش منبع درشت‌تر است و باید به عنوان یک مرز شبکه و نه یک سامانه هویت در نظر گرفته شود.
تمایزهای دقیق‌تر متعلق به برنامه است. شنونده پایگاه داده‌ای که باید برای بیشتر کارکنان بسته بماند، با دسترس‌ناپذیر بودن کامل روی پیشوند مجاز بهتر محافظت می‌شود تا با امید به مرتب ماندن عضویت گروه.
تغییر نام گروه هویتی ایجاد نمی‌کند و تکرار آن برای هر تیم فقط انجمن‌های نیازمند حسابرسی را چند برابر می‌کند.
آن قاعده را به هر طراحی VPN کپی نکنید
دروازه EC2 VPN خودگردان، دستگاه بازرسی مسیریابی‌شده و Client VPN مدیریت‌شده سه مسیر بسته متفاوت هستند. مشخص کنید کدام نشانی منبع واقعاً به منبع می‌رسد، آیا در میانه ترجمه رخ می‌دهد و سرویس روی آن مسیر از کدام سازوکارهای ارجاع پشتیبانی می‌کند.
عبور ترافیک از یک دستگاه میانی ارجاع گروه امنیتی منبع را آن‌گونه که ترافیک مستقیم نمونه‌به‌نمونه حفظ می‌کند حفظ نمی‌کند. AWS مستند می‌کند که چنین طراحی‌هایی ممکن است به جای ارجاع گروه به نشانی‌های خصوصی منبع یا CIDR مناسب نیاز داشته باشند. رویه Client VPN مدیریت‌شده شاهدی بر این نیست که گروه متصل هر دروازه به عنوان نشانه هویت جهانی برای بسته‌های ارسال‌شده عمل می‌کند.
یک پرش NAT در مسیر برای شکستن این فرض کافی است و خرابی شبیه قاعده‌ای به نظر می‌رسد که وجود دارد اما هرگز مطابقت نمی‌کند.
مرز مؤثر را بازبینی کنید
هر گروه امنیتی متصل به منبع را بخوانید، زیرا قواعد اجازه با هم جمع می‌شوند و یک قاعده تنگ قاعده گسترده‌تر روی گروه دیگر را لغو نمی‌کند. سپس ACL شبکه، فایروال میزبان و مجوزدهی خود برنامه را بررسی کنید که لایه‌های جدا با خطاهای جدا هستند.
با یک درخواست مجاز و یک درخواست عمداً حذف‌شده علیه همان منبع تمام کنید. این جفت مرز را اثبات می‌کند، در حالی که یک اتصال موفق تنها نشان می‌دهد چیزی باز است. مسیر، منبع مؤثر و پورت سرویس مورد نظر را تأیید کنید، نه زیرشبکه‌ای که نقطه پایانی را در خود دارد.
ترتیب کار: الزام چهاربخشی را بنویسید، گروه را به انجمن‌ها متصل کنید، قاعده منبع را به پورت محدود کنید، یک اجازه و یک رد را بررسی کنید و تنها پس از آن تقسیم زیرشبکه‌ها به دلایل مسیریابی را در نظر بگیرید.