Hvorfor EC2 ikke når AWS Client VPN-laptopen din
Client VPN oversetter IPv4-klientkilder til endepunktets nettverksgrensesnitt. Derfor virker svaret, men en ny forbindelse fra EC2 gjør det ikke.
En laptop som er koblet til via AWS Client VPN, når en EC2-applikasjon uten problemer. Så prøver du det motsatte, fra EC2 til adressen klienten fikk tildelt, og forbindelsen henger eller avvises. Den asymmetrien er sjelden en manglende sikkerhetsgrupperegel. På et Client VPN-endepunkt som er knyttet til VPC-subnett, oversetter AWS IPv4-klientkilder til endepunktets nettverksgrensesnitt, så det finnes ingen inngående VPC-adresse som representerer laptopen din.
Begynn med det opptaket viser
Ta et opptak på EC2-verten mens klienten kobler til, og les kildeadressen applikasjonen faktisk ser. Hvis det er endepunktets grensesnitt på VPC-siden og ikke en adresse fra klientpoolen, er oversettelsen bekreftet før du endrer en eneste regel.
Klientpoolen er et tildelingsområde, ikke et subnett med en returrute. Det er på denne forskjellen de fleste slike undersøkelser går galt.
Oversettelsen som forklarer asymmetrien
Tre strømmer blir forvekslet med hverandre, og bare én av dem er den 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 av Client VPN-komponentene sier uttrykkelig at IPv4-klientkilder oversettes til endepunktets grensesnitt, og det er nok til å se hvorfor den midterste raden ikke har noe å matche.
En ny forbindelse trenger en rute, et adresseoppslagstrinn og en autorisasjonsbeslutning. Oversettelsestilstand fra en annens sesjon gir ingen av de tre.
Hvorfor et svar ikke er en ny forbindelse
Et TCP-svar matches mot en eksisterende oppføring, og derfor virker returveien helt uten noen inngående regel. Et ferskt SYN fra EC2-verten har ingen oppføring å matche, så det blir et vanlig utgående forsøk mot en destinasjon som VPC-en ikke vet hvordan den skal nå.
Det er også derfor det er misvisende å beskrive dette som trafikk som bare går én vei. Returtrafikken flyter kontinuerlig i disse sesjonene. Det er igangsettingen som mangler en vei.
Hva som fortsatt ødelegger en sesjon som burde virke
Sikkerhetsgrupper, nettverks-ACL-er og laptopens egen brannmur betyr alt for forbindelsene som skal lykkes. En mislykket ping sier minst, fordi ICMP-policyen ofte er atskilt fra TCP-policyen du bryr deg om.
Skriv disse reglene mot den oversatte kilden, ikke klientadressen. Regler som er knyttet til adressen som aldri vises på nettet, er den vanligste selvforskyldte feilen i dette designet.
Når VPC-en virkelig må starte samtalen
Hvis en tjeneste skal varsle en arbeidsstasjon, snu retningen og la klienten holde en vedvarende utgående kanal som tjenesten svarer på. Hvis et helt eksternt nettverk må være tilgjengelig fra VPC-en, velg en arkitektur som publiserer prefiksene og tilgangspolicyen sin i stedet for å anta at Client VPN allerede gjør det. Klient-til-klient-tilgang er et tredje, snevrere tilfelle med egne rute- og autorisasjonsobjekter. Ingen av disse er en avkrysningsboks på det eksisterende endepunktet.
Hold også omfanget av IPv4-forklaringen ærlig. Gjeldende AWS-dokumentasjon skiller ut IPv6, der denne oversettelsen ikke brukes, og andre tilkoblingsmodeller som ruter annerledes.
Test i tre merkede trinn: klienten åpner en tillatt sesjon, VPC-tjenesten svarer på den sesjonen, og en VPC-vert åpner en ny sesjon mot klienten. At de to første lykkes mens den tredje feiler, er den forventede formen for dette designet, ikke en feil som skal jages med brannmurregler.