Skupni Transit Gateway: kdo ima v lasti poti v AWS RAM

Deljenje Transit Gateway prek Resource Access Manager naredi eno konkretno stvar: drugemu računu omogoči, da pokliče določen nabor API-jev za pripenjanje na vir, ki ga ne poseduje. Ne prenese prehoda, njegovih tabel poti ali pravice odločati, kako se promet posreduje. Ljudje predpostavljajo nasprotno, ker se pripenjanje pojavi v konzoli prejemnika in takoj deluje, kar se zdi kot lastništvo. Mehanizem pod tem je dodelitev dovoljenja na deljenem viru, in vsak podrejeni objekt ostane znotraj meje računa lastnika. Ta delitev pojasnjuje večino zahtevkov za zavrnjen dostop okoli deljenega tranzita.

Kaj deljenje dejansko delegira

Deljenje vira poimenuje vir, principal in upravljano dovoljenje. Dovoljenje našteje dejanja, ki jih ta principal lahko izvede, in za Transit Gateway ta seznam zajema operacije pripenjanja na deljenem viru.

Vse izven seznama spodleti v API-ju in ne v konzoli, zato se napaka pogosto pojavi ob prvem zagonu skripta.

Tabele poti, povezave in razširitve ostanejo pri lastniku

Posredovanje določajo trije podrejeni objekti: s katero tabelo poti je povezano pripenjanje, v katere tabele se razširi in katere poti vsebujejo te tabele. Dokumentacija AWS o deljenju navaja, da prejemnik prek deljenja ne more ustvariti, spremeniti ali izbrisati tabel poti tranzitnega prehoda niti njihovih povezav in razširitev. Ti klici pripadajo računu lastnika. Prejemnik, ki potrebuje novo povezavo, prosi za administrativno spremembo, ne uveljavlja dovoljenja, ki ga je pozabil omogočiti.

Tabela spodaj je delitev, ki jo dajem v načrtovalske dokumente, ker preživi kadrovske spremembe.

Pozorno preberite srednjo vrstico: lastnik VPC-ja nadzoruje poti svoje podomrežje, lastnik prehoda nadzoruje osrednjo odločitev o posredovanju, in delujoča pot potrebuje oboje. Noben od računov tega ne more dokončati sam.

Ena pot, dva računa

Sledite paketu od spoke VPC do krajevnega prefiksa. Tabela poti spoke podomrežja mora ta prefiks poslati na pripenjanje tranzitnega prehoda, kar lahko lastnik VPC-ja spremeni. Nato mora imeti prehod v povezani tabeli pripenjanja pot, ki kaže na pripenjanje VPN, in to lahko spremeni le lastnik. Povratni promet potrebuje zrcalno sliko obeh. Če zgrešite katero koli stran, dobite na pol nameščeno pot, ki je videti kot težava s požarnim zidom.

Obe spremembi zapišite v en zahtevek z dvema odgovornima, sicer bosta dokončani v različnih tednih.

Uporabite ID-je območij razpoložljivosti, ko je postavitev pomembna

Imena območij so lokalni vzdevki računa. us-east-1a v enem računu ni zagotovljeno isto fizično območje kot us-east-1a v drugem. Ko načrt zahteva pripenjanje in delovno obremenitev v istem območju, primerjajte ID-je AZ in jih zabeležite.

Primerjanje imen ustvari diagram, ki je videti pravilen, in profil zakasnitve, ki ni. Preverite to, medtem ko se diagram še riše, ne potem, ko je nekdo izmeril razliko.

Preklic deljenja ne prekine podatkovne poti

Odstranitev deljenja se zdi kot preklic in ni takojšnja ustavitev prometa. AWS dokumentira, da pripenjanje ostane delujoče, ko prehod ni več deljen. Dovoljenje za upravljanje vira izgine, medtem ko obstoječe pripenjanje še naprej posreduje, dokler ga nekdo ne izbriše ali onemogoči. Načrtujte preklic v dveh korakih: odstranite deljenje, nato pripenjanje, pri čemer drugega izvede lastnik.

Če je deljenje vaša edina kontrola, nimate kontrole.

Hranite zapis o deljenju in zapis o usmerjanju skupaj

Dva artefakta odgovarjata na dve različni vprašanji. Zapis o deljenju pove, kdo sme delati z virom. Tabele poti povejo, katera omrežja lahko resnično govorijo. Shranite jih skupaj z istim seznamom lastnikov, sicer se bo naslednji incident začel z nekom, ki dokazuje dovoljenje, ki nikoli ni bilo težava.

Nato preizkusite en tok v vsako smer in en prefiks, ki mora ostati nedosegljiv.