EC2 över tillgänglighetszoner: kontrollera routningen före en VPN

Innan du installerar VPN-programvara mellan två EC2-instanser ska du besvara en fråga: är de i samma VPC? Om de är det finns den privata vägen redan, och en placering över zoner ändrar inte det. Det mesta av arbetet i den här situationen är att bekräfta vilken routningstabell varje subnät faktiskt använder, och sedan ta reda på om felet överhuvudtaget var ett routningsproblem. En tunnel är oftast det felaktiga svaret på just den här frågan.

Kontroll 1: samma VPC eller olika VPC:er

En VPC är regional och sträcker sig över tillgänglighetszoner, medan varje subnät tillhör exakt en zon. Två instanser i olika zoner i samma VPC ligger fortfarande inom samma privata routningsdomän.

Olika VPC:er får aldrig en privat rutt bara för att de delar en region eller en zonetikett. Det fallet kräver en anslutning som stöds och eget arbete med rutter och behörigheter, vilket är ett separat beslut.

Kontroll 2: vad subnätens routningstabeller säger

Skriv ned upplägget med riktiga värden. En VPC på 10.60.0.0/16 med subnät 10.60.1.0/24 och 10.60.2.0/24 ger instanserna 10.60.1.10 och 10.60.2.20 en väg via VPC:ns lokala rutt.

Undersök sedan tabellerna som är kopplade till båda subnäten, inte bara den du hittade först. En mer specifik inspektions- eller apparatrutt kan åsidosätta basrutten, och målet för den lokala rutten kan självt bytas ut i nyare konfigurationer. En lokal rutt som syns någonstans i konsolen bevisar inte att båda arbetslasterna använder den.

Använd de privata adresser och namn som VPC:n faktiskt tilldelar. En privat adress behöver inte börja med 10, och att hitta på en ur minnet är sättet en fungerande miljö feldiagnostiseras på.

Kontroll 3: routning eller auktorisering

Routning tar bara paketet till målets nätverksgränssnitt. Målets säkerhetsgrupp måste fortfarande släppa igenom källan och tjänsten, källans utgående regler måste tillåta begäran, och en eventuell nätverks-ACL måste tillåta båda riktningarna eftersom ACL:er inte håller tillstånd.

Bakom det ligger gästens brandvägg, lyssnarens bindning och applikationens egen identitet. Var och en av dem kan neka en begäran som routningen levererade perfekt.

Acceptansen måste vara den verkliga applikationsoperationen. Ett lyckat ping ger inte applikationsåtkomst och bevisar inte att ett TLS-namn och inloggningsuppgifter är korrekta, och ett blockerat ping visar inte att varje privat tjänst ligger nere.

Kontroll 4: krävs verkligen en separat anslutning

En VPN kan fortfarande höra hemma i designen, men av ett angivet skäl: att koppla den här VPC:n till ett kontor, släppa in bärbara datorer eller uppfylla ett överläggskrav. Det skälet skiljer sig från vanlig kommunikation inom samma VPC.

Kom också ihåg vad VPC:n inte är. Den är inte en förlängning av ett hemma-Ethernet-segment. En applikation som är beroende av broadcast-upptäckt har ett eget krav att utvärdera. Det är en lucka i designen och inte ett routningsfel.

Kontroll 5: krypteringsfrågan

En privat adress och en tillåtelseregel säger ingenting om kryptografiskt skydd på applikationslagret. Om data behöver skydd från ände till ände kommer det från protokollet och identitetsmodellen som tjänsten faktiskt stöder.

Håll påståenden om nätverkslagret och applikationslagret åtskilda i designanteckningen, för att slå ihop dem är sättet en granskning till slut hävdar skydd som ingen har implementerat.

Vad som ska registreras

Registrera båda subnätens ID, routningstabellen som är kopplad till varje, säkerhetsgruppernas referenser och applikationsoperationen du testade. Det är fyra fakta, och de avgör de flesta framtida diskussioner om den här vägen.

Enbart zonplacering säger aldrig till dig att lägga till en VPN, och den förklarar aldrig varför en privat begäran misslyckades.