Hvorfor EC2 ikke kan nå din AWS Client VPN-laptop
Client VPN oversætter IPv4-klientkilder til endpointets netværksgrænseflade. Derfor virker svaret, men en ny forbindelse fra EC2 gør ikke.
En laptop, der er forbundet via AWS Client VPN, når en EC2-applikation uden problemer. Så prøver du det omvendte, fra EC2 til den adresse, klienten fik tildelt, og forbindelsen hænger eller afvises. Den asymmetri er sjældent en manglende sikkerhedsgrupperegel. På et Client VPN-endpoint, der er knyttet til VPC-undernet, oversætter AWS IPv4-klientkilder til endpointets netværksgrænseflade, så der findes ingen indgående VPC-adresse, der repræsenterer din laptop.
Begynd med det, optagelsen viser
Lav en optagelse på EC2-værten, mens klienten forbinder, og læs den kildeadresse, applikationen faktisk ser. Hvis det er endpointets grænseflade på VPC-siden og ikke en adresse fra klientpuljen, er oversættelsen bekræftet, før du ændrer en eneste regel.
Klientpuljen er et tildelingsområde, ikke et undernet med en returrute. Det er den forskel, hvor de fleste af disse undersøgelser går galt.
Den oversættelse, der forklarer asymmetrien
Tre flows bliver forvekslet med hinanden, og kun ét af dem er det, folk tester.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Beskrivelsen af Client VPN-komponenterne siger udtrykkeligt, at IPv4-klientkilder oversættes til endpointets grænseflade, og det er nok til at se, hvorfor den midterste række ikke har noget at matche.
En ny forbindelse kræver en rute, et adresseopløsningstrin og en autorisationsbeslutning. Oversættelsestilstand fra en andens session giver ingen af de tre.
Hvorfor et svar ikke er en ny forbindelse
Et TCP-svar matches mod en eksisterende post, og derfor virker returvejen helt uden en indgående regel. Et friskt SYN fra EC2-værten har ingen post at matche, så det bliver et almindeligt udgående forsøg mod en destination, som VPC'en ikke ved, hvordan den skal nå.
Det er også derfor, det er misvisende at beskrive det som trafik, der kun går én vej. Returtrafik flyder uafbrudt i disse sessioner. Det er igangsættelsen, der mangler en vej.
Hvad stadig ødelægger en session, der burde virke
Sikkerhedsgrupper, netværks-ACL'er og laptopens egen firewall betyder alle noget for de forbindelser, der skal lykkes. En mislykket ping siger mindst, fordi ICMP-politik ofte er adskilt fra den TCP-politik, du bekymrer dig om.
Skriv de regler mod den oversatte kilde, ikke klientadressen. Regler, der er knyttet til den adresse, der aldrig vises på nettet, er den mest almindelige selvforskyldte fejl i dette design.
Når VPC'en virkelig skal starte samtalen
Hvis en tjeneste skal underrette en arbejdsstation, skal du vende retningen og lade klienten holde en vedvarende udgående kanal, som tjenesten svarer på. Hvis et helt fjernnetværk skal kunne nås fra VPC'en, vælg en arkitektur, der offentliggør sine præfikser og adgangspolitik i stedet for at antage, at Client VPN allerede gør det. Klient-til-klient-adgang er et tredje, snævrere tilfælde med sine egne rute- og autorisationsobjekter. Ingen af disse er en afkrydsningsboks på det eksisterende endpoint.
Hold også omfanget af IPv4-forklaringen ærligt. Den nuværende AWS-dokumentation adskiller IPv6, hvor den oversættelse ikke anvendes, og andre tilslutningsmodeller, der router anderledes.
Test i tre mærkede trin: klienten åbner en tilladt session, VPC-tjenesten svarer på den session, og en VPC-vært åbner en ny session mod klienten. At de to første lykkes, mens den tredje fejler, er den forventede form for dette design, ikke en fejl, der skal jages med firewallregler.