EC2 v zónách dostupnosti: před VPN zkontrolujte směrování

Než nainstalujete software VPN mezi dvě instance EC2, odpovězte na jednu otázku: jsou ve stejném VPC? Pokud ano, privátní cesta už existuje a umístění do různých zón to nemění. Většina práce v této situaci spočívá v potvrzení, kterou směrovací tabulku každá podsíť skutečně používá, a poté ve zjištění, zda porucha vůbec byla problém směrování. Tunel je na tuto konkrétní otázku obvykle špatná odpověď.

Kontrola 1: stejné VPC, nebo různá VPC

VPC je regionální a zahrnuje zóny dostupnosti, zatímco každá podsíť patří právě do jedné zóny. Dvě instance v různých zónách jednoho VPC jsou stále uvnitř stejné domény privátního směrování.

Různá VPC nikdy nezískají privátní trasu jen proto, že sdílejí region nebo označení zóny. Takový případ vyžaduje podporované připojení a vlastní práci s trasami a oprávněními, což je samostatné rozhodnutí.

Kontrola 2: co říkají směrovací tabulky podsítí

Zapište uspořádání se skutečnými hodnotami. VPC na adrese 10.60.0.0/16 s podsítěmi 10.60.1.0/24 a 10.60.2.0/24 dává instancím 10.60.1.10 a 10.60.2.20 cestu přes lokální trasu VPC.

Poté prohlédněte tabulky přiřazené k oběma podsítím, ne jen tu, kterou jste našli první. Konkrétnější trasa inspekce nebo zařízení může přepsat základní trasu a cíl lokální trasy může být v novějších konfiguracích sám nahrazen. Lokální trasa viditelná někde v konzoli nedokazuje, že ji používají obě úlohy.

Použijte privátní adresy a názvy, které VPC skutečně přiděluje. Privátní adresa nemusí začínat na 10 a vymýšlení adresy z paměti je způsob, jak špatně diagnostikovat funkční prostředí.

Kontrola 3: směrování, nebo autorizace

Směrování dostane paket jen k síťovému rozhraní cíle. Bezpečnostní skupina cíle stále musí pustit zdroj a službu, odchozí pravidla zdroje musí povolit požadavek a jakýkoli síťový ACL musí povolit oba směry, protože ACL si nepamatují stav.

Za tím stojí firewall hosta, navázání naslouchajícího procesu a vlastní identita aplikace. Každý z nich může odmítnout požadavek, který směrování doručilo bezchybně.

Přijetí musí být skutečná operace aplikace. Úspěšný ping nedává přístup k aplikaci ani nedokazuje, že název TLS a přihlašovací údaje jsou správné, a zablokovaný ping neprokazuje, že všechny privátní služby nefungují.

Kontrola 4: je samostatné připojení vůbec nutné

VPN může do návrhu stále patřit, ale z uvedeného důvodu: připojit toto VPC ke kanceláři, pustit notebooky nebo splnit požadavek na překryvnou síť. Tento důvod se liší od běžné komunikace ve stejném VPC.

Pamatujte také, co VPC není. Není to rozšíření domácího ethernetového segmentu. Aplikace, která závisí na objevování vysíláním, má samostatný požadavek k posouzení. To je mezera v návrhu, ne chyba směrování.

Kontrola 5: otázka šifrování

Privátní adresa a povolovací pravidlo neříkají nic o kryptografické ochraně na aplikační vrstvě. Pokud data potřebují ochranu od konce ke konci, přichází z protokolu a modelu identity, které služba skutečně podporuje.

Držte tvrzení o síťové a aplikační vrstvě v poznámce k návrhu odděleně, protože jejich sloučení je způsob, jak recenze nakonec tvrdí ochranu, kterou nikdo nezavedl.

Co zaznamenat

Zaznamenejte oba identifikátory podsítí, směrovací tabulku přiřazenou ke každé z nich, odkazy na bezpečnostní skupiny a operaci aplikace, kterou jste testovali. To jsou čtyři fakta a ta vyřeší většinu budoucích sporů o tuto cestu.

Pouhé umístění v zóně vám nikdy neřekne, abyste přidali VPN, a nikdy nevysvětlí, proč privátní požadavek selhal.