Egy helyek közötti VPN több VPC-hez az AWS Transit Gatewayen

Csatlakoztassa a VPN-t egyszer és minden VPC-t egyetlen tranzitátjáróhoz, majd válassza szét a társítást a propagálástól, hogy a spoke-ok elérjék az irodát, de egymást ne.

Két VPC-nek ebben a negyedévben szüksége van az irodai hálózatra, és éppen a második alagútnál törik meg a becslés. Az AWS Transit Gateway közös útválasztó központként működhet: a VPN egyszer csatlakozik, és minden VPC ugyanahhoz a központhoz csatlakozik. Ezután a helyszíni hálózat egyetlen kapcsolaton keresztül éri el az összes csatlakoztatott VPC-t. Ez megváltoztatja, kié az útválasztási döntés, és a legtöbb terv éppen ezt rontja el.

A VPN-csatoló és a VPC-csatolók külön objektumok ugyanazon az átjárón, ezért az útválasztási viszonyokat utólag kell felépíteni.

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

Miért nem a peering az a rövidítés, amiben bíznak

A csábító alternatíva, hogy a VPN-t a VPC A-n fejezzük be, és a VPC B-t peeringgel hozzákapcsoljuk. A szokásos VPC-peering nem ad éltől élig terjedő átjárást az A VPN-kapcsolatán keresztül. A peer csak azokat a címeket éri el, amelyeket maga a peering biztosít, és a VPN-él nem tartozik közéjük. Az átjárást a központ adja; a peering egy párt ad.

Ez a korlátozás a peering tulajdonsága, nem emelhető kvóta.

A társítás és a propagálás különböző munkát végez

A tranzitátjárón belül a társítás választja ki azt az útválasztási táblát, amellyel a csatolóról érkező forgalmat keressük. A propagálás dönti el, mely táblák kapják meg egy csatoló tanult vagy kapcsolt előtagjait. Egy csatoló egy táblához társítható, miközben több táblába propagál. A kettő összekeverése az, ahogy egy terv senki által nem tervezett elérhetőséghez jut.

A teljesen összekapcsolt kis központ az egyszerű eset.

Tegyen minden csatolót egyetlen táblába, és a VPN a két VPC-előtaggal együtt tisztán feloldódik. Ez engedélyezi a VPC-k közötti elérhetőséget is, amit a szervezet talán soha nem akart, mert a közös tábla nem ismeri a spoke fogalmát.

A munkaterhelések útvonalai máshol laknak

Minden munkaterhelés-alhálózatnak továbbra is szüksége van saját útvonalára a tranzitátjáró felé a tervezett helyi előtagokhoz. Azok a VPC-útválasztási táblák külön objektumok a tranzitátjáró saját tábláitól. Adja hozzá a szükséges előtagokat, és őrizze meg a meglévő útvonalakat ahelyett, hogy minden célt új alapértelmezettel helyettesítene. Az alhálózati útvonal sem hirdet semmit az ügyfél eszköze felé.

Válassza a dinamikus vagy statikus útválasztást szándékosan; a peering egyiket sem nyújtja.

Különítse el a spoke-okat helyi hozzáférés nélkül

Amikor A és B egyaránt elérheti az irodát, de nem útválaszthatnak egymás felé, ossza szét a táblákat. A VPN-csatoló társított táblája tartalmazza a VPC-előtagokat. A VPC-csatolók társított táblája tartalmazza a helyi előtagokat, anélkül hogy bármilyen útvonal összekötné A-t B-vel. Ezt a viszonyt a propagálás hozza létre, így soha nem kell elfogadnia minden alapértelmezett társítást.

Ez útválasztási elkülönítés, és nem alkalmazásengedélyezés.

A biztonsági csoportok, a hálózati ACL-ek, a gazdagépek tűzfalai és az egyes szolgáltatások saját jogosultságai továbbra is eldöntik, milyen forgalmat fogadnak el. Ha vizsgálat szükséges, tervezze meg annak támogatott útvonalát kifejezetten, ahelyett hogy feltételezné, a központ elvégzi.

Amit a központ nem javít meg

A címterveknek továbbra sem szabad átfedniük, mert a központ nem engedi, hogy egy előtag két munkaterhelést jelöljön. Minden VPC-csatolónak szüksége van arra az Availability Zone-lefedettségre, amelyet a munkaterhelései elvárnak. BGP-vel az ügyfél eszközének útvonalai minden szükséges előtag felé meg kell feleljenek a tervnek és annak importszabályának. A hiányzó hirdetés pontosan úgy néz ki, mint egy törött alagút.

A VPN-kapcsolat és a tranzitátjáró most közös infrastruktúra.

Tervezze meg az alagutak redundanciáját, az eszközkapacitást, a megfigyelést és a karbantartást minden függő VPC körül, ahelyett hogy mindegyiket függetlenül csatlakoztatottként kezelné.

A meglévő virtual private gateway elrendezésről való migráció ugyanazt a kifejezett tervet érdemli. Építse fel a csatolókat és a szabályzatokat, mozgasson át egy ellenőrzött munkaterhelés-útvonalat, és erősítse meg az engedélyezett és tiltott viszonyokat, mielőtt a régi útvonalat kivonja. A központosítás segít, amikor egy helyet ad a hálózati csapatnak a közös kapcsolódás kezelésére, és árt, amikor egyetlen nagy tábla mögé rejti, ki kiket érhet el.

Kapcsolódó cikkek