Споделен 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 контролира маршрутите на своята подмрежа, собственикът на шлюза контролира централното решение за препращане и работещият път се нуждае от двете. Нито един от двата акаунта не може да го завърши сам.
Един път, два акаунта
Проследете пакет от spoke VPC до локален префикс. Таблицата с маршрути на spoke подмрежата трябва да изпрати този префикс към прикачването на транзитния шлюз, което собственикът на VPC може да промени. След това шлюзът трябва да има маршрут в свързаната таблица на прикачването, сочещ към VPN прикачването, което само собственикът може да промени. Връщащият трафик се нуждае от огледалото на двете. Пропуснете която и да е страна и получавате път, инсталиран наполовина, който изглежда като проблем със защитната стена.
Запишете двете промени в един тикет с двама отговорници, иначе ще бъдат завършени в различни седмици.
Използвайте ID на зони за достъпност, когато разположението е важно
Имената на зоните са локални за акаунта псевдоними. us-east-1a в един акаунт не е гарантирано, че е същата физическа зона като us-east-1a в друг. Когато проектът изисква прикачване и работно натоварване в една и съща зона, сравнете AZ ID и ги запишете.
Сравняването на имена дава диаграма, която изглежда правилна, и профил на закъснение, който не е. Проверете го, докато диаграмата още се чертае, а не след като някой измери разликата.
Премахването на споделянето не прекъсва пътя на данните
Премахването на споделянето се усеща като отнемане, но не е незабавно спиране на трафика. AWS документира, че прикачването остава функционално, когато шлюзът бъде изваден от споделянето. Разрешението за управление на ресурса изчезва, докато съществуващото прикачване продължава да препраща, докато някой не го изтрие или деактивира. Планирайте отнемането на две стъпки: премахнете споделянето, после прикачването, като собственикът извършва второто.
Ако споделянето е единственият ви контрол, нямате контрол.
Пазете записа за споделянето и записа за маршрутизацията заедно
Два артефакта отговарят на два различни въпроса. Записът за споделянето казва кой може да работи с ресурса. Таблиците с маршрути казват кои мрежи действително могат да говорят. Съхранявайте ги заедно със същия списък на собствениците, иначе следващият инцидент започва с някого, който доказва разрешение, което никога не е било проблемът.
След това тествайте един поток във всяка посока и един префикс, който трябва да остане недостъпен.