EC2 over beschikbaarheidszones: controleer routing vóór een VPN

Voordat u VPN-software tussen twee EC2-instanties installeert, beantwoordt u één vraag: zitten ze in dezelfde VPC? Zo ja, dan bestaat het privépad al en een plaatsing over zones verandert dat niet. Het meeste werk in deze situatie is bevestigen welke routetabel elk subnet werkelijk gebruikt, en vervolgens uitzoeken of de storing überhaupt een routeringsprobleem was. Een tunnel is meestal het verkeerde antwoord op deze specifieke vraag.

Controle 1: dezelfde VPC of verschillende VPC's

Een VPC is regionaal en omvat beschikbaarheidszones, terwijl elk subnet tot precies één zone behoort. Twee instanties in verschillende zones van één VPC bevinden zich nog steeds in hetzelfde privé-routeringsdomein.

Verschillende VPC's krijgen nooit een privéroute alleen omdat ze een regio of een zonelabel delen. Dat geval vereist een ondersteunde verbinding en eigen werk aan routes en machtigingen, wat een aparte beslissing is.

Controle 2: wat de routetabellen van de subnetten zeggen

Schrijf de opzet op met echte waarden. Een VPC op 10.60.0.0/16 met subnetten 10.60.1.0/24 en 10.60.2.0/24 geeft de instanties 10.60.1.10 en 10.60.2.20 een pad via de lokale route van de VPC.

Bekijk daarna de tabellen die aan beide subnetten zijn gekoppeld, niet alleen degene die u het eerst vond. Een specifiekere inspectie- of apparaatroute kan de basisroute overschrijven, en het doel van de lokale route kan in nieuwere configuraties zelf worden vervangen. Een lokale route die ergens in de console zichtbaar is, bewijst niet dat beide workloads die gebruiken.

Gebruik de privéadressen en namen die de VPC werkelijk toekent. Een privéadres hoeft niet met 10 te beginnen, en er een uit het geheugen verzinnen is de manier waarop een werkende omgeving verkeerd wordt gediagnosticeerd.

Controle 3: routing of autorisatie

Routing brengt het pakket alleen naar de netwerkinterface van het doel. De beveiligingsgroep van het doel moet de bron en de dienst nog steeds toelaten, de uitgaande regels van de bron moeten het verzoek toestaan, en elke netwerk-ACL moet beide richtingen toestaan omdat ACL's geen status bijhouden.

Daarachter zitten de firewall van de gast, de binding van de listener en de identiteit van de toepassing zelf. Elk daarvan kan een verzoek weigeren dat routing perfect heeft afgeleverd.

De acceptatie moet de echte toepassingsbewerking zijn. Een geslaagde ping geeft geen toegang tot de toepassing en bewijst niet dat een TLS-naam en inloggegevens correct zijn, en een geblokkeerde ping stelt niet vast dat elke privédienst uit ligt.

Controle 4: is een aparte verbinding echt nodig

Een VPN kan nog steeds in het ontwerp horen, maar om een genoemde reden: deze VPC met een kantoor verbinden, laptops toelaten of aan een overlay-eis voldoen. Die reden verschilt van gewone communicatie binnen dezelfde VPC.

Bedenk ook wat de VPC niet is. Het is geen uitbreiding van een huiselijk Ethernet-segment. Een toepassing die afhankelijk is van broadcast-detectie heeft een aparte eis om te beoordelen. Dat is een ontwerpgat en geen routeringsfout.

Controle 5: de versleutelingsvraag

Een privéadres en een toestemmingsregel zeggen niets over cryptografische bescherming op de toepassingslaag. Als de gegevens end-to-end-bescherming nodig hebben, komt die van het protocol en het identiteitsmodel dat de dienst werkelijk ondersteunt.

Houd uitspraken over de netwerklaag en de toepassingslaag gescheiden in de ontwerpnotitie, want ze samenvoegen is de manier waarop een beoordeling uiteindelijk bescherming beweert die niemand heeft geïmplementeerd.

Wat u moet vastleggen

Leg beide subnet-ID's vast, de routetabel die aan elk is gekoppeld, de verwijzingen naar de beveiligingsgroepen en de toepassingsbewerking die u hebt getest. Dat zijn vier feiten, en ze beslechten de meeste toekomstige discussies over dit pad.

Zonepositie alleen zegt u nooit dat u een VPN moet toevoegen, en het verklaart nooit waarom een privéverzoek is mislukt.