Transit Gateway مشترک: مالکیت مسیرها در AWS RAM
اشتراکگذاری RAM به حساب دیگری اجازه میدهد VPC را متصل کند، اما جداول مسیر، انجمنها و انتشارها نزد مالک دروازه میمانند. مرز همینجاست.
اشتراکگذاری یک Transit Gateway با Resource Access Manager یک کار مشخص میکند: به حساب دیگری اجازه میدهد مجموعه تعریفشدهای از APIهای اتصال را روی منبعی که مالک آن نیست فراخوانی کند. این کار دروازه، جداول مسیر آن یا حق تصمیمگیری درباره نحوه ارسال ترافیک را منتقل نمیکند. مردم خلاف آن را فرض میکنند چون اتصال در کنسول گیرنده ظاهر میشود و فوراً کار میکند، که حس مالکیت میدهد. سازوکار زیرین اعطای مجوز روی یک منبع مشترک است و هر شیء فرزند در مرز حساب مالک باقی میماند. همین تفکیک بیشتر تیکتهای رد دسترسی پیرامون عبور مشترک را توضیح میدهد.
اشتراکگذاری واقعاً چه چیزی را واگذار میکند
اشتراکگذاری منبع یک منبع، یک اصل و یک مجوز مدیریتشده را نام میبرد. مجوز اقداماتی را فهرست میکند که آن اصل میتواند انجام دهد، و برای یک Transit Gateway آن فهرست عملیات اتصال روی منبع مشترک را پوشش میدهد.
هر چیزی بیرون از فهرست در API شکست میخورد نه در کنسول، به همین دلیل خطا اغلب نخستین بار که اسکریپت اجرا میشود ظاهر میشود.
جداول مسیر، انجمنها و انتشارها نزد مالک میمانند
ارسال توسط سه شیء فرزند تعیین میشود: اتصال با کدام جدول مسیر انجمن شده، به کدام جداول منتشر میشود و آن جداول چه مسیرهایی دارند. مستندات اشتراکگذاری AWS میگوید گیرنده نمیتواند از طریق اشتراکگذاری جداول مسیر دروازه عبور یا انجمنها و انتشارهای آنها را ایجاد، تغییر یا حذف کند. این فراخوانیها متعلق به حساب مالک است. گیرندهای که به انجمن جدید نیاز دارد درخواست تغییر اداری میکند، نه اعمال مجوزی که فعال کردنش را فراموش کرده است.
جدول زیر همان تفکیکی است که در اسناد طراحی میگذارم، چون از تغییر کارکنان جان سالم به در میبرد.
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
ردیف میانی را با دقت بخوانید: مالک VPC مسیرهای زیرشبکه خود را کنترل میکند، مالک دروازه تصمیم مرکزی ارسال را کنترل میکند، و یک مسیر کارآمد به هر دو نیاز دارد. هیچیک از دو حساب نمیتواند آن را تنها کامل کند.
یک مسیر، دو حساب
یک بسته را از VPC شعاعی تا یک پیشوند محلی دنبال کنید. جدول مسیر زیرشبکه شعاعی باید آن پیشوند را به اتصال دروازه عبور بفرستد، که مالک VPC میتواند تغییرش دهد. سپس دروازه باید در جدول انجمنشده اتصال مسیری داشته باشد که به اتصال VPN اشاره کند، که فقط مالک میتواند تغییرش دهد. ترافیک برگشتی به تصویر آینهای هر دو نیاز دارد. هر طرف را جا بیندازید و مسیری نیمهنصبشده میگیرید که شبیه مشکل دیوار آتش است.
هر دو تغییر را در یک تیکت با دو مسئول بنویسید، وگرنه در هفتههای مختلف تمام میشوند.
وقتی مکان مهم است از شناسههای منطقه دسترسپذیری استفاده کنید
نام مناطق نامهای مستعار محلی حساب هستند. us-east-1a در یک حساب تضمین نمیشود همان منطقه فیزیکی us-east-1a در حساب دیگر باشد. وقتی طراحی به اتصال و بار کاری در یک منطقه نیاز دارد، شناسههای AZ را مقایسه و ثبت کنید.
مقایسه نامها نموداری میسازد که درست به نظر میرسد و نمایه تأخیری که درست نیست. این را زمانی بررسی کنید که نمودار هنوز در حال رسم است، نه بعد از اینکه کسی تفاوت را اندازه گرفت.
لغو اشتراکگذاری مسیر داده را قطع نمیکند
حذف اشتراکگذاری شبیه لغو به نظر میرسد و توقف فوری ترافیک نیست. AWS مستند میکند که اتصال وقتی دروازه از اشتراک خارج میشود همچنان کار میکند. مجوز مدیریت منبع ناپدید میشود، در حالی که اتصال موجود تا وقتی کسی آن را حذف یا غیرفعال نکند به ارسال ادامه میدهد. لغو را دو مرحلهای برنامهریزی کنید: اشتراک را بردارید، سپس اتصال را، و مالک مرحله دوم را انجام دهد.
اگر اشتراکگذاری تنها کنترل شماست، کنترلی ندارید.
سابقه اشتراک و سابقه مسیریابی را کنار هم نگه دارید
دو مصنوع به دو پرسش متفاوت پاسخ میدهند. سابقه اشتراک میگوید چه کسی میتواند با منبع کار کند. جداول مسیر میگویند کدام شبکهها واقعاً میتوانند صحبت کنند. آنها را با همان فهرست مالکان ذخیره کنید، وگرنه حادثه بعدی با کسی شروع میشود که مجوزی را اثبات میکند که هرگز مشکل نبود.
سپس یک جریان در هر جهت و یک پیشوندی را آزمایش کنید که باید دستنیافتنی بماند.