Dva VPC-a trebaju uredsku mrežu ovog kvartala, a upravo na drugom tunelu procjena pada. AWS Transit Gateway može poslužiti kao zajedničko središte za rutiranje: VPN se priključuje jednom, a svaki VPC se priključuje na isto središte. Lokalna mreža zatim doseže svaki priključeni VPC kroz jednu vezu. To mijenja ko posjeduje odluku o rutiranju, a to je dio koji većina dizajna pogrešno shvati.

Priključak VPN-a i priključci VPC-a odvojeni su objekti na istom gatewayu, zato se odnosi rutiranja moraju izgraditi naknadno.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Zašto peering nije prečica kojoj se ljudi nadaju

Mamljiva alternativa je završiti VPN na VPC A i povezati VPC B s njim peeringom. Obični VPC peering ne pruža tranzit od ruba do ruba kroz VPN vezu VPC-a A. Peer doseže adrese koje sam peering pruža, a VPN rub nije jedna od njih. Tranzit je ono što daje središte; peering daje par.

To ograničenje je svojstvo peeringa, a ne kvota koju možete podići.

Asocijacija i propagacija rade različit posao

Unutar tranzitnog gatewaya asocijacija bira tablicu ruta koja se koristi za traženje prometa koji dolazi s priključka. Propagacija odlučuje koje tablice primaju naučene ili povezane prefikse nekog priključka. Jedan se priključak može asocijacijom vezati za jednu tablicu, a propagirati u nekoliko. Miješanje tih dvaju pojmova način je na koji dizajn završi s dostupnošću koju nitko nije planirao.

Potpuno povezano malo središte lak je slučaj.

Stavite svaki priključak u jednu tablicu i VPN se zajedno s oba prefiksa VPC-a čisto razrješava. To također dopušta dostupnost između VPC-a koju organizacija možda nikad nije namjeravala, jer zajednička tablica ne poznaje pojam spoke-a.

Rute radnih opterećenja žive negdje drugdje

Svaka podmreža radnog opterećenja još uvijek treba vlastitu rutu prema tranzitnom gatewayu za predviđene lokalne prefikse. Te tablice ruta VPC-a odvojeni su objekti od vlastitih tablica tranzitnog gatewaya. Dodajte potrebne prefikse i sačuvajte postojeće rute umjesto da svako odredište zamijenite novim defaultom. Ruta podmreže također ništa ne oglašava korisničkom uređaju.

Odaberite dinamičko ili statičko rutiranje svjesno; peering ne pruža ni jedno.

Izolirajte spoke-ove bez gubitka lokalnog pristupa

Kad A i B oba mogu doći do ureda, ali ne smiju rutirati jedan prema drugome, razdvojite tablice. Asocirana tablica priključka VPN-a drži prefikse VPC-a. Asocirana tablica priključaka VPC-a drži lokalne prefikse, bez rute koja spaja A s B. Propagacija stvara taj odnos, pa nikad ne morate prihvatiti svaku zadanu asocijaciju.

To je izolacija rutiranja, a ne autorizacija aplikacije.

Sigurnosne grupe, mrežni ACL-ovi, host vatrozidi i vlastita dopuštenja svake usluge i dalje odlučuju koji se promet prihvaća. Ako je potreban pregled, projektirajte njegov podržani put izričito umjesto da pretpostavite da ga središte obavlja.

Što središte ne rješava

Planovi adresa i dalje moraju biti bez preklapanja, jer središte ne dopušta da jedan prefiks označi dva radna opterećenja. Svaki priključak VPC-a treba pokrivenost Availability Zone koju njegova radna opterećenja očekuju. Uz BGP, rute korisničkog uređaja natrag prema svakom potrebnom prefiksu moraju odgovarati dizajnu i njegovoj politici uvoza. Oglašavanje koje nedostaje izgleda točno kao pokvaren tunel.

VPN veza i tranzitni gateway sada su zajednička infrastruktura.

Planirajte redundantnost tunela, kapacitet uređaja, nadzor i održavanje oko svih ovisnih VPC-a umjesto da svaki tretirate kao zasebno povezan.

Migracija s postojećeg rasporeda virtual private gatewaya zaslužuje isti izričit plan. Izgradite priključke i politike, premjestite jedan kontrolirani put radnog opterećenja i potvrdite dopuštene i odbijene odnose prije nego što umirovite stari put. Centralizacija pomaže kad mrežnom timu daje jedno mjesto za upravljanje zajedničkom povezanošću, a šteti kad skriva kto smije doći do koga iza jedne velike tablice.

Povezani članci