EC2 elérhetőségi zónák között: VPN előtt ellenőrizze az útválasztást

Mielőtt VPN-szoftvert telepítene két EC2-példány közé, válaszoljon egy kérdésre: ugyanabban a VPC-ben vannak? Ha igen, a privát útvonal már létezik, és a zónák közötti elhelyezés ezen nem változtat. A munka nagy része ebben a helyzetben annak megerősítése, hogy melyik útválasztási táblát használja valójában az egyes alhálózat, majd annak kiderítése, hogy a hiba egyáltalán útválasztási probléma volt-e. Az alagút általában rossz válasz erre a konkrét kérdésre.

Ellenőrzés 1: ugyanaz a VPC vagy különböző VPC-k

A VPC regionális, és elérhetőségi zónákra terjed ki, míg minden alhálózat pontosan egy zónához tartozik. Két példány egy VPC különböző zónáiban továbbra is ugyanazon privát útválasztási tartományon belül van.

A különböző VPC-k soha nem kapnak privát útvonalat csak azért, mert közös régiót vagy zónacímkét használnak. Ez az eset támogatott kapcsolatot, valamint saját útvonal- és jogosultságmunkát igényel, ami külön döntés.

Ellenőrzés 2: mit mondanak az alhálózatok útválasztási táblái

Írja fel az elrendezést valós értékekkel. Egy VPC, amelynek címe 10.60.0.0/16 és alhálózatai 10.60.1.0/24 és 10.60.2.0/24, a példányoknak 10.60.1.10 és 10.60.2.20 utat ad a VPC helyi útvonalán.

Ezután vizsgálja meg mindkét alhálózathoz tartozó táblákat, ne csak azt, amelyiket először megtalálta. Egy konkrétabb ellenőrzési vagy eszközútvonal felülírhatja az alapútvonalat, és a helyi útvonal célja maga is helyettesíthető az újabb konfigurációkban. A konzolban valahol látható helyi útvonal nem bizonyítja, hogy mindkét számítási feladat használja.

Használja azokat a privát címeket és neveket, amelyeket a VPC valóban kioszt. Egy privát címnek nem kell 10-zel kezdődnie, és a memóriából kitalált cím az, ahogyan egy működő környezetet félrediagnosztizálnak.

Ellenőrzés 3: útválasztás vagy engedélyezés

Az útválasztás csak eljuttatja a csomagot a cél hálózati interfészéhez. A cél biztonsági csoportjának továbbra is engedélyeznie kell a forrást és a szolgáltatást, a forrás kimenő szabályainak engedélyezniük kell a kérést, és minden hálózati ACL-nek mindkét irányt engedélyeznie kell, mert az ACL-ek nem tárolnak állapotot.

Ezek mögött a vendég tűzfala, a figyelő kötése és az alkalmazás saját identitása áll. Mindegyik elutasíthat egy kérést, amelyet az útválasztás hibátlanul kézbesített.

Az elfogadásnak a valódi alkalmazásműveletnek kell lennie. A sikeres ping nem ad hozzáférést az alkalmazáshoz, és nem bizonyítja, hogy a TLS-név és a hitelesítő adatok helyesek, a blokkolt ping pedig nem bizonyítja, hogy minden privát szolgáltatás leállt.

Ellenőrzés 4: valóban szükség van-e külön kapcsolatra

A VPN továbbra is része lehet a tervezésnek, de megadott okból: ennek a VPC-nek az irodához csatlakoztatása, laptopok beengedése vagy overlay-követelmény teljesítése. Ez az ok különbözik az ugyanazon VPC-n belüli szokásos kommunikációtól.

Ne feledje azt sem, mi nem a VPC. Nem egy otthoni Ethernet-szegmens kiterjesztése. Egy broadcast-felderítéstől függő alkalmazásnak külön értékelendő követelménye van. Ez tervezési hiányosság, nem útválasztási hiba.

Ellenőrzés 5: a titkosítás kérdése

Egy privát cím és egy engedélyező szabály semmit nem mond az alkalmazási réteg kriptográfiai védelméről. Ha az adatoknak végponttól végpontig terjedő védelemre van szükségük, az abból a protokollból és identitásmodellből származik, amelyet a szolgáltatás valóban támogat.

Tartsa külön a hálózati és az alkalmazási réteg állításait a tervezési feljegyzésben, mert ezek összemosása az, ahogyan egy felülvizsgálat végül olyan védelmet állít, amelyet senki nem valósított meg.

Mit kell rögzíteni

Rögzítse mindkét alhálózati azonosítót, a mindegyikhez tartozó útválasztási táblát, a biztonsági csoportok hivatkozásait és a tesztelt alkalmazásműveletet. Ez négy tény, és ezek eldöntik az erről az útvonalról szóló legtöbb jövőbeli vitát.

A zónába helyezés önmagában soha nem mondja azt, hogy adjon hozzá VPN-t, és soha nem magyarázza meg, miért hiúsult meg egy privát kérés.