Een laptop die via AWS Client VPN is verbonden, bereikt een EC2-toepassing zonder problemen. Daarna probeer je het omgekeerde, van EC2 naar het adres dat de client kreeg, en de verbinding blijft hangen of wordt geweigerd. Die asymmetrie is zelden een ontbrekende beveiligingsgroepsregel. Op een Client VPN-endpoint dat aan VPC-subnetten is gekoppeld, vertaalt AWS IPv4-clientsources naar de netwerkinterface van het endpoint, dus er is geen inkomend VPC-adres dat je laptop vertegenwoordigt.

Begin met wat de capture laat zien

Maak een capture op de EC2-host terwijl de client verbindt en lees het bronadres dat de toepassing werkelijk ziet. Als dat de endpointinterface aan de VPC-kant is en niet een adres uit de clientpool, is de vertaling bevestigd voordat je één regel wijzigt.

De clientpool is een toewijzingsbereik, geen subnet met een terugroute. Op dat onderscheid gaan de meeste van dit soort onderzoeken mis.

De vertaling die de asymmetrie verklaart

Drie stromen worden met elkaar verward, en slechts één ervan is degene die mensen testen.

FlowStarted byWhat the VPC seesOutcome
Client to EC2 serviceThe clientA translated source at the endpoint interfaceWorks, with a stateful reply
EC2 host to client pool addressThe EC2 hostA destination with no route and no translation stateNo usable path
Client to clientA client, when the feature is configuredTraffic mediated by the endpointWorks only with that feature and its authorisation

De beschrijving van de Client VPN-componenten zegt uitdrukkelijk dat IPv4-clientsources naar de endpointinterface worden vertaald, en dat is genoeg om te zien waarom de middelste rij niets heeft om mee te vergelijken.

Een nieuwe verbinding heeft een route, een adresoplossingsstap en een autorisatiebeslissing nodig. Vertaalstatus uit iemands anders sessie levert geen van de drie.

Waarom een antwoord geen nieuwe verbinding is

Een TCP-antwoord wordt tegen een bestaande vermelding gematcht, daarom werkt de terugweg helemaal zonder inkomende regel. Een verse SYN van de EC2-host heeft geen vermelding om tegen te matchen, dus het wordt een gewone uitgaande poging naar een bestemming die de VPC niet weet te bereiken.

Daarom is het ook misleidend om dit te beschrijven als verkeer dat maar één kant op gaat. Terugverkeer stroomt in deze sessies voortdurend. Het deel zonder pad is de initiatie.

Wat een sessie die zou moeten werken alsnog breekt

Beveiligingsgroepen, netwerk-ACL's en de firewall van de laptop zelf doen er allemaal toe voor de verbindingen die moeten slagen. Een mislukte ping zegt het minst, omdat ICMP-beleid vaak losstaat van het TCP-beleid dat je aangaat.

Schrijf die regels tegen de vertaalde bron, niet het clientadres. Regels die vastzitten aan het adres dat nooit op het netwerk verschijnt, zijn de meest voorkomende zelfveroorzaakte fout in dit ontwerp.

Wanneer de VPC het gesprek echt moet beginnen

Als een dienst een werkstation moet informeren, draai de richting om en laat de client een blijvend uitgaand kanaal houden waarop de dienst antwoordt. Als een heel extern netwerk vanaf de VPC bereikbaar moet zijn, kies dan een architectuur die zijn prefixen en toegangsbeleid publiceert in plaats van aan te nemen dat Client VPN dat al doet. Client-naar-clienttoegang is een derde, smaller geval met zijn eigen route- en autorisatieobjecten. Niets daarvan is een selectievakje op het bestaande endpoint.

Houd ook de reikwijdte van de IPv4-uitleg eerlijk. De huidige AWS-documentatie scheidt IPv6, waar die vertaling niet geldt, en andere verbindingsmodellen die anders routeren.

Test in drie gelabelde stappen: de client opent een toegestane sessie, de VPC-dienst antwoordt op die sessie, en een VPC-host opent een nieuwe sessie naar de client. Dat de eerste twee slagen terwijl de derde faalt, is de verwachte vorm van dit ontwerp, geen defect dat je met firewallregels moet najagen.

Gerelateerde artikelen