EC2 kroz zone dostupnosti: provjerite rutiranje prije VPN-a

Prije instaliranja VPN softvera između dvije EC2 instance, odgovorite na jedno pitanje: jesu li u istom VPC-u? Ako jesu, privatna putanja već postoji i smještanje u različite zone to ne mijenja. Većina posla u ovoj situaciji je potvrditi koju tablicu ruta svaka podmreža zapravo koristi, a zatim otkriti je li kvar uopće bio problem rutiranja. Tunel je obično pogrešan odgovor na ovo konkretno pitanje.

Provjera 1: isti VPC ili različiti VPC-ovi

VPC je regionalan i pokriva zone dostupnosti, dok svaka podmreža pripada točno jednoj zoni. Dvije instance u različitim zonama jednog VPC-a i dalje su unutar istog domena privatnog rutiranja.

Različiti VPC-ovi nikada ne dobijaju privatnu rutu samo zato što dijele regiju ili oznaku zone. Taj slučaj zahtijeva podržanu vezu i vlastiti rad na rutama i dozvolama, što je odvojena odluka.

Provjera 2: šta kažu tablice ruta podmreža

Zapišite raspored sa stvarnim vrijednostima. VPC na adresi 10.60.0.0/16 sa podmrežama 10.60.1.0/24 i 10.60.2.0/24 daje instancama 10.60.1.10 i 10.60.2.20 putanju kroz lokalnu rutu VPC-a.

Zatim pregledajte tablice povezane s obje podmreže, a ne samo onu koju ste prvu pronašli. Specifičnija ruta za inspekciju ili uređaj može nadjačati osnovnu, a cilj lokalne rute može i sam biti zamijenjen u novijim konfiguracijama. Lokalna ruta vidljiva negdje u konzoli ne dokazuje da je koriste oba radna opterećenja.

Koristite privatne adrese i imena koje VPC zaista dodjeljuje. Privatna adresa ne mora počinjati s 10, a izmišljanje adrese po sjećanju je način da se radno okruženje pogrešno dijagnostikuje.

Provjera 3: rutiranje ili autorizacija

Rutiranje samo dovodi paket do mrežnog interfejsa cilja. Sigurnosna grupa cilja i dalje mora propustiti izvor i uslugu, izlazna pravila izvora moraju dopustiti zahtjev, a bilo koji mrežni ACL mora dopustiti oba smjera jer ACL-ovi ne pamte stanje.

Iza toga stoje gostujući firewall, vezivanje slušača i vlastiti identitet aplikacije. Svaki od njih može odbiti zahtjev koji je rutiranje savršeno dostavilo.

Prihvatanje mora biti stvarna aplikacijska operacija. Uspješan ping ne daje pristup aplikaciji niti dokazuje da su TLS ime i vjerodajnice ispravni, a blokiran ping ne dokazuje da su sve privatne usluge prekinute.

Provjera 4: je li odvojena veza zaista potrebna

VPN i dalje može pripadati dizajnu, ali zbog navedenog razloga: povezivanje ovog VPC-a s uredom, prihvatanje laptopa ili ispunjavanje zahtjeva za overlay mrežu. Taj je razlog drugačiji od uobičajene komunikacije unutar istog VPC-a.

Sjetite se i šta VPC nije. On nije produžetak kućnog Ethernet segmenta. Aplikacija koja zavisi od broadcast otkrivanja ima odvojen zahtjev koji treba procijeniti. To je praznina u dizajnu, a ne greška u rutiranju.

Provjera 5: pitanje šifriranja

Privatna adresa i pravilo dopuštanja ne govore ništa o kriptografskoj zaštiti na sloju aplikacije. Ako podaci trebaju zaštitu od kraja do kraja, ona dolazi iz protokola i modela identiteta koje usluga zapravo podržava.

Držite tvrdnje o mrežnom i aplikacijskom sloju odvojeno u bilješci o dizajnu, jer njihovo spajanje je način na koji pregled na kraju tvrdi zaštitu koju niko nije implementirao.

Šta zabilježiti

Zabilježite oba ID-a podmreže, tablicu ruta povezanu sa svakom, reference sigurnosnih grupa i aplikacijsku operaciju koju ste testirali. To su četiri činjenice i one rješavaju većinu budućih rasprava o ovoj putanji.

Samo smještanje u zonu nikada vam ne kaže da dodate VPN i nikada ne objašnjava zašto je privatni zahtjev neuspješan.