EC2 kroz zone dostupnosti: provjerite usmjeravanje prije VPN-a
Dvije EC2 instance u istom VPC-u već dijele privatno usmjeravanje između zona. Provjerite tablice podmreža i pravila pristupa prije dodavanja novog tunela.
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 usmjeravanja svaka podmreža zapravo koristi, a zatim otkriti je li kvar uopće bio problem usmjeravanja. 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 iste domene privatnog usmjeravanja.
Različiti VPC-ovi nikada ne dobivaju 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: što kažu tablice ruta podmreža
Zapišite raspored sa stvarnim vrijednostima. VPC na adresi 10.60.0.0/16 s 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 dijagnosticira.
Provjera 3: usmjeravanje ili autorizacija
Usmjeravanje samo dovodi paket do mrežnog sučelja 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 vatrozid, vezivanje slušatelja i vlastiti identitet aplikacije. Svaki od njih može odbiti zahtjev koji je usmjeravanje savršeno dostavilo.
Prihvaćanje 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, prihvaćanje prijenosnika ili ispunjavanje zahtjeva za overlay mrežu. Taj je razlog drugačiji od uobičajene komunikacije unutar istog VPC-a.
Sjetite se i što VPC nije. On nije proširenje kućnog Ethernet segmenta. Aplikacija koja ovisi o broadcast otkrivanju ima odvojen zahtjev koji treba procijeniti. To je praznina u dizajnu, a ne greška u usmjeravanju.
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 nitko nije implementirao.
Što 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.