EC2 på tvers av tilgjengelege soner: kontroller ruttinga før ein VPN

Før du installerer VPN-programvare mellom to EC2-instansar, må du svare på eitt spørsmål: er dei i same VPC? Viss dei er det, finst den private vegen allereie, og ein plassering på tvers av soner endrar ikkje det. Det meste av arbeidet i denne situasjonen er å stadfeste kva rutetabell kvart subnett faktisk brukar, og deretter finne ut om feilen i det heile var eit ruteproblem. Ein tunnel er vanlegvis det gale svaret på nettopp dette spørsmålet.

Kontroll 1: same VPC eller ulike VPC-ar

Ein VPC er regional og spenner over tilgjengelege soner, medan kvart subnett høyrer til nøyaktig éi sone. To instansar i ulike soner i same VPC er framleis innanfor same private rutedomene.

Ulike VPC-ar får aldri ei privat rute berre fordi dei deler ein region eller ein soneetikett. Det tilfellet krev ei støtta tilkopling og eige arbeid med ruter og løyve, som er eit separat vedtak.

Kontroll 2: kva subnett sine rutetabellar seier

Skriv ned oppsettet med reelle verdiar. Ein VPC på 10.60.0.0/16 med subnett 10.60.1.0/24 og 10.60.2.0/24 gjev instansane 10.60.1.10 og 10.60.2.20 ein veg gjennom den lokale ruta til VPC-en.

Undersøk deretter tabellane som er knytte til begge subnetta, ikkje berre den du fann først. Ei meir spesifikk inspeksjons- eller apparatrute kan overstyre basisruta, og målet for den lokale ruta kan sjølv bli erstatta i nyare konfigurasjonar. Ei lokal rute som er synleg ein stad i konsollen, beviser ikkje at begge arbeidslastene brukar henne.

Bruk dei private adressene og namna som VPC-en faktisk tildeler. Ei privat adresse treng ikkje å byrje med 10, og å finne opp ei frå minnet er måten eit fungerande miljø blir feildiagnostisert på.

Kontroll 3: rutting eller autorisasjon

Rutting bringar berre pakken til nettverksgrensesnittet til målet. Sikkerhetsgruppa til målet må framleis sleppe til kjelda og tenesta, dei utgåande reglane til kjelda må tillate førespurnaden, og ein eventuell nettverks-ACL må tillate begge retningar fordi ACL-ar ikkje hugsar tilstand.

Bak det ligg brannmuren til gjesten, bindinga til lyttaren og identiteten til applikasjonen sjølv. Kvar av dei kan avvise ein førespurnad som ruttinga leverte perfekt.

Aksepten må vere den verkelege applikasjonsoperasjonen. Ein vellukka ping gjev ikkje applikasjonstilgang og beviser ikkje at eit TLS-namn og påloggingsinformasjon er rette, og ein blokkert ping fastslår ikkje at kvar privat teneste er nede.

Kontroll 4: er ei separat tilkopling verkeleg nødvendig

Ein VPN kan framleis høyre heime i designet, men av ein oppgitt grunn: å kople denne VPC-en til eit kontor, sleppe inn berbare datamaskiner eller oppfylle eit overleggskrav. Den grunnen er annleis enn vanleg kommunikasjon innanfor same VPC.

Hugs òg kva VPC-en ikkje er. Han er ikkje ei forlenging av eit heime-Ethernet-segment. Ein applikasjon som er avhengig av kringkastingsbasert oppdaging, har eit eige krav som må vurderast. Det er eit hol i designet og ikkje ein rutefeil.

Kontroll 5: krypteringsspørsmålet

Ei privat adresse og ein løyveregel seier ingenting om kryptografisk vern på applikasjonslaget. Viss dataa treng vern frå ende til ende, kjem det frå protokollen og identitetsmodellen som tenesta faktisk støttar.

Hald påstandar om nettverkslaget og applikasjonslaget åtskilde i designnotatet, fordi å slå dei saman er måten ein gjennomgang endar med å hevde vern som ingen har implementert.

Kva som skal registrerast

Registrer begge subnett-ID-ane, rutetabellen knytt til kvar av dei, sikkerhetsgruppereferansane og applikasjonsoperasjonen du testa. Det er fire fakta, og dei avgjer dei fleste framtidige diskusjonar om denne vegen.

Soneplassering åleine fortel deg aldri å leggje til ein VPN, og ho forklarer aldri kvifor ein privat førespurnad mislykkast.