EC2 på tværs af tilgængelighedszoner: kontroller routing før en VPN

Før du installerer VPN-software mellem to EC2-instanser, skal du besvare ét spørgsmål: er de i samme VPC? Hvis de er, findes den private vej allerede, og en placering på tværs af zoner ændrer ikke det. Det meste af arbejdet i denne situation er at bekræfte, hvilken rutetabel hvert subnet faktisk bruger, og derefter finde ud af, om fejlen overhovedet var et routingproblem. En tunnel er normalt det forkerte svar på netop dette spørgsmål.

Kontrol 1: samme VPC eller forskellige VPC'er

En VPC er regional og spænder over tilgængelighedszoner, mens hvert subnet hører til præcis én zone. To instanser i forskellige zoner i samme VPC er stadig inden for samme private routingdomæne.

Forskellige VPC'er får aldrig en privat rute, bare fordi de deler en region eller en zonebetegnelse. Det tilfælde kræver en understøttet forbindelse og eget arbejde med ruter og tilladelser, hvilket er en separat beslutning.

Kontrol 2: hvad subnettenes rutetabeller siger

Skriv opsætningen ned med rigtige værdier. En VPC på 10.60.0.0/16 med subnets 10.60.1.0/24 og 10.60.2.0/24 giver instanserne 10.60.1.10 og 10.60.2.20 en vej gennem VPC'ens lokale rute.

Undersøg derefter tabellerne, der er knyttet til begge subnets, og ikke kun den, du fandt først. En mere specifik inspektions- eller apparatrute kan tilsidesætte basisruten, og den lokale rutes mål kan selv blive erstattet i nyere konfigurationer. En lokal rute, der er synlig et sted i konsollen, beviser ikke, at begge arbejdsbelastninger bruger den.

Brug de private adresser og navne, som VPC'en faktisk tildeler. En privat adresse behøver ikke at begynde med 10, og at opfinde en fra hukommelsen er måden at fejldiagnosticere et fungerende miljø på.

Kontrol 3: routing eller autorisation

Routing bringer kun pakken til målets netværksgrænseflade. Målets sikkerhedsgruppe skal stadig tillade kilden og tjenesten, kildens udgående regler skal tillade anmodningen, og en eventuel netværks-ACL skal tillade begge retninger, fordi ACL'er ikke husker tilstand.

Bag det ligger gæstens firewall, lytterens binding og applikationens egen identitet. Hver af dem kan afvise en anmodning, som routing leverede perfekt.

Accept skal være den rigtige applikationshandling. Et vellykket ping giver ikke adgang til applikationen og beviser ikke, at et TLS-navn og legitimationsoplysninger er korrekte, og et blokeret ping fastslår ikke, at alle private tjenester er nede.

Kontrol 4: er en separat forbindelse egentlig nødvendig

En VPN kan stadig høre til i designet, men af en angivet grund: at forbinde denne VPC med et kontor, lukke laptops ind eller opfylde et krav om overlay. Den grund er anderledes end almindelig kommunikation i samme VPC.

Husk også, hvad VPC'en ikke er. Den er ikke en forlængelse af et hjemme-Ethernet-segment. En applikation, der afhænger af broadcast-opdagelse, har et særskilt krav, der skal vurderes. Det er et hul i designet og ikke en routingfejl.

Kontrol 5: spørgsmålet om kryptering

En privat adresse og en tilladelsesregel siger intet om kryptografisk beskyttelse på applikationslaget. Hvis dataene har brug for ende-til-ende-beskyttelse, kommer den fra den protokol og identitetsmodel, som tjenesten faktisk understøtter.

Hold påstande om netværkslag og applikationslag adskilt i designnotatet, fordi sammenblanding er måden, hvorpå en gennemgang ender med at hævde beskyttelse, som ingen har implementeret.

Hvad der skal registreres

Registrer begge subnet-id'er, rutetabellen knyttet til hver af dem, sikkerhedsgruppereferencerne og den applikationshandling, du testede. Det er fire fakta, og de afgør de fleste fremtidige diskussioner om denne vej.

Zoneplacering alene fortæller dig aldrig at tilføje en VPN, og den forklarer aldrig, hvorfor en privat anmodning fejlede.