EC2 در مناطق دسترسپذیری: پیش از VPN مسیریابی را بررسی کنید
دو نمونه EC2 در یک VPC از قبل مسیریابی خصوصی میان مناطق را به اشتراک میگذارند. پیش از افزودن تونل دیگری، جدولهای زیرشبکه و قواعد دسترسی را بررسی کنید.
پیش از نصب نرمافزار VPN میان دو نمونه EC2، به یک پرسش پاسخ دهید: آیا در یک VPC هستند؟ اگر چنین است، مسیر خصوصی از قبل وجود دارد و قرارگیری میان مناطق آن را تغییر نمیدهد. بیشتر کار در این وضعیت تأیید این نکته است که هر زیرشبکه در واقع از کدام جدول مسیر استفاده میکند و سپس کشف این که آیا این خرابی اصلاً مشکل مسیریابی بوده است. تونل معمولاً پاسخ نادرستی به این پرسش مشخص است.
بررسی 1: همان VPC یا VPCهای متفاوت
یک VPC منطقهای است و مناطق دسترسپذیری را در بر میگیرد، در حالی که هر زیرشبکه دقیقاً به یک منطقه تعلق دارد. دو نمونه در مناطق مختلف یک VPC همچنان درون همان دامنه مسیریابی خصوصی قرار دارند.
VPCهای متفاوت هرگز فقط به دلیل اشتراک در یک منطقه یا برچسب منطقه، مسیر خصوصی به دست نمیآورند. آن حالت به یک اتصال پشتیبانیشده و کار جداگانه روی مسیرها و مجوزها نیاز دارد که تصمیمی مستقل است.
بررسی 2: جدولهای مسیر زیرشبکهها چه میگویند
چیدمان را با مقادیر واقعی بنویسید. یک VPC با نشانی 10.60.0.0/16 و زیرشبکههای 10.60.1.0/24 و 10.60.2.0/24 به نمونههای 10.60.1.10 و 10.60.2.20 مسیری از طریق مسیر محلی VPC میدهد.
سپس جدولهای مرتبط با هر دو زیرشبکه را بررسی کنید، نه فقط جدولی که نخست پیدا کردید. یک مسیر بازرسی یا دستگاه مشخصتر میتواند مسیر پایه را کنار بگذارد، و مقصد مسیر محلی خود میتواند در پیکربندیهای جدیدتر جایگزین شود. دیدن یک مسیر محلی در جایی از کنسول اثبات نمیکند که هر دو بار کاری از آن استفاده میکنند.
از نشانیها و نامهای خصوصیای استفاده کنید که VPC در واقع تخصیص میدهد. نشانی خصوصی لازم نیست با 10 شروع شود، و ساختن یکی از حافظه همان راهی است که یک محیط سالم اشتباه تشخیص داده میشود.
بررسی 3: مسیریابی یا مجوزدهی
مسیریابی فقط بسته را به رابط شبکه مقصد میرساند. گروه امنیتی مقصد همچنان باید مبدأ و سرویس را بپذیرد، قواعد خروجی مبدأ باید درخواست را مجاز کند، و هر ACL شبکه باید هر دو جهت را مجاز کند زیرا ACLها حالتمند نیستند.
فراتر از آن، دیوار آتش میزبان، اتصال شنونده و هویت خود برنامه قرار دارند. هر یک میتواند درخواستی را رد کند که مسیریابی آن را بینقص رسانده است.
پذیرش باید همان عملیات واقعی برنامه باشد. یک ping موفق دسترسی به برنامه نمیدهد و ثابت نمیکند که نام TLS و اعتبارنامه درست هستند، و ping مسدودشده ثابت نمیکند که هر سرویس خصوصی از کار افتاده است.
بررسی 4: آیا واقعاً اتصال جداگانه لازم است
VPN میتواند همچنان بخشی از طراحی باشد، اما به دلیلی اعلامشده: اتصال این VPC به یک دفتر، پذیرش لپتاپها یا برآورده کردن نیاز یک لایه پوششی. این دلیل با ارتباط معمول درون یک VPC متفاوت است.
همچنین به یاد داشته باشید VPC چه چیزی نیست. این یک گسترش از یک قطعه اترنت خانگی نیست. برنامهای که به کشف از طریق پخش وابسته است نیاز جداگانهای برای ارزیابی دارد. این یک شکاف طراحی است نه باگ مسیریابی.
بررسی 5: پرسش رمزنگاری
یک نشانی خصوصی و یک قاعده مجاز هیچ چیزی درباره حفاظت رمزنگاری در لایه برنامه نمیگویند. اگر دادهها به حفاظت سرتاسری نیاز دارند، این از پروتکل و مدل هویتی میآید که سرویس واقعاً پشتیبانی میکند.
ادعاهای لایه شبکه و لایه برنامه را در یادداشت طراحی جدا نگه دارید، زیرا ادغام آنها همان راهی است که یک بازبینی در نهایت حفاظتی را ادعا میکند که هیچکس پیادهسازی نکرده است.
چه چیزی را ثبت کنید
هر دو شناسه زیرشبکه، جدول مسیر مرتبط با هر یک، ارجاعهای گروه امنیتی و عملیات برنامهای را که آزمودید ثبت کنید. اینها چهار واقعیت هستند و بیشتر بحثهای آینده درباره این مسیر را حل میکنند.
قرارگیری در یک منطقه بهتنهایی هرگز به شما نمیگوید VPN اضافه کنید و هرگز توضیح نمیدهد که چرا یک درخواست خصوصی شکست خورده است.