EC2 på tvers av tilgjengelighetssoner: kontroller ruting før en VPN

Før du installerer VPN-programvare mellom to EC2-instanser, må du svare på ett spørsmål: er de i samme VPC? Hvis de er det, finnes den private veien allerede, og en plassering på tvers av soner endrer ikke det. Det meste av arbeidet i denne situasjonen er å bekrefte hvilken rutetabell hvert subnett faktisk bruker, og deretter finne ut om feilen i det hele tatt var et rutingproblem. En tunnel er vanligvis det gale svaret på nettopp dette spørsmålet.

Kontroll 1: samme VPC eller forskjellige VPC-er

En VPC er regional og spenner over tilgjengelighetssoner, mens hvert subnett tilhører nøyaktig én sone. To instanser i forskjellige soner i samme VPC er fortsatt innenfor samme private rutingdomene.

Forskjellige VPC-er får aldri en privat rute bare fordi de deler en region eller en soneetikett. Det tilfellet krever en støttet tilkobling og eget arbeid med ruter og tillatelser, som er en separat beslutning.

Kontroll 2: hva subnettenes rutetabeller sier

Skriv ned oppsettet med reelle verdier. En VPC på 10.60.0.0/16 med subnett 10.60.1.0/24 og 10.60.2.0/24 gir instansene 10.60.1.10 og 10.60.2.20 en vei gjennom VPC-ens lokale rute.

Undersøk deretter tabellene som er knyttet til begge subnettene, ikke bare den du fant først. En mer spesifikk inspeksjons- eller apparatrute kan overstyre basisruten, og målet for den lokale ruten kan selv bli erstattet i nyere konfigurasjoner. En lokal rute som er synlig et sted i konsollen, beviser ikke at begge arbeidsbelastningene bruker den.

Bruk de private adressene og navnene som VPC-en faktisk tildeler. En privat adresse trenger ikke å begynne med 10, og å finne opp en fra hukommelsen er måten et fungerende miljø blir feildiagnostisert på.

Kontroll 3: ruting eller autorisasjon

Ruting bringer bare pakken til målets nettverksgrensesnitt. Målets sikkerhetsgruppe må fortsatt tillate kilden og tjenesten, kildens utgående regler må tillate forespørselen, og en eventuell nettverks-ACL må tillate begge retninger fordi ACL-er ikke husker tilstand.

Bak det ligger gjestens brannmur, lytterens binding og applikasjonens egen identitet. Hver av dem kan avvise en forespørsel som rutingen leverte perfekt.

Aksept må være den ekte applikasjonsoperasjonen. En vellykket ping gir ikke applikasjonstilgang og beviser ikke at et TLS-navn og påloggingsinformasjon er riktige, og en blokkert ping fastslår ikke at hver privat tjeneste er nede.

Kontroll 4: er en separat tilkobling egentlig nødvendig

En VPN kan fortsatt høre hjemme i designet, men av en oppgitt grunn: å koble denne VPC-en til et kontor, slippe inn bærbare datamaskiner eller oppfylle et overleggskrav. Den grunnen er forskjellig fra vanlig kommunikasjon innenfor samme VPC.

Husk også hva VPC-en ikke er. Den er ikke en forlengelse av et hjemme-Ethernet-segment. En applikasjon som er avhengig av kringkastingsbasert oppdagelse, har et eget krav som må vurderes. Det er et hull i designet og ikke en rutingfeil.

Kontroll 5: krypteringsspørsmålet

En privat adresse og en tillatelsesregel sier ingenting om kryptografisk beskyttelse på applikasjonslaget. Hvis dataene trenger ende-til-ende-beskyttelse, kommer den fra protokollen og identitetsmodellen som tjenesten faktisk støtter.

Hold påstander om nettverkslaget og applikasjonslaget adskilt i designnotatet, fordi å slå dem sammen er måten en gjennomgang ender med å hevde beskyttelse som ingen har implementert.

Hva som skal registreres

Registrer begge subnett-ID-ene, rutetabellen knyttet til hver av dem, sikkerhetsgruppereferansene og applikasjonsoperasjonen du testet. Det er fire fakta, og de avgjør de fleste fremtidige diskusjoner om denne veien.

Soneplassering alene forteller deg aldri å legge til en VPN, og den forklarer aldri hvorfor en privat forespørsel mislyktes.