Varför EC2 inte når din AWS Client VPN-laptop
Client VPN översätter IPv4-klientkällor till slutpunktens nätverksgränssnitt. Därför fungerar svaret men en ny anslutning från EC2 inte.
En laptop som är ansluten via AWS Client VPN når en EC2-applikation utan problem. Sedan provar du det omvända, från EC2 till adressen klienten tilldelades, och anslutningen hänger eller nekas. Den asymmetrin är sällan en saknad säkerhetsgruppsregel. På en Client VPN-slutpunkt som är kopplad till VPC-subnät översätter AWS IPv4-klientkällor till slutpunktens nätverksgränssnitt, så det finns ingen inkommande VPC-adress som representerar din laptop.
Börja med vad avlyssningen visar
Gör en avlyssning på EC2-värden medan klienten ansluter och läs den källadress som applikationen faktiskt ser. Om det är slutpunktens gränssnitt på VPC-sidan och inte en adress från klientpoolen, är översättningen bekräftad innan du ändrar en enda regel.
Klientpoolen är ett tilldelningsintervall, inte ett subnät med en returväg. Det är på den skillnaden de flesta sådana här utredningar går fel.
Översättningen som förklarar asymmetrin
Tre flöden blandas ihop med varandra, och bara ett av dem är det som folk testar.
| 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 |
Beskrivningen av Client VPN-komponenterna säger uttryckligen att IPv4-klientkällor översätts till slutpunktens gränssnitt, och det räcker för att se varför den mittersta raden inte har något att matcha.
En ny anslutning behöver en rutt, ett adressupplösningssteg och ett auktoriseringsbeslut. Översättningstillstånd från någon annans session ger inget av de tre.
Varför ett svar inte är en ny anslutning
Ett TCP-svar matchas mot en befintlig post, och därför fungerar returvägen helt utan någon inkommande regel. Ett färskt SYN från EC2-värden har ingen post att matcha, så det blir ett vanligt utgående försök mot en destination som VPC:n inte vet hur den ska nå.
Det är också därför det är missvisande att beskriva detta som trafik som bara går åt ett håll. Returtrafiken flödar oavbrutet i dessa sessioner. Det är initieringen som saknar en väg.
Vad som fortfarande bryter en session som borde fungera
Säkerhetsgrupper, nätverks-ACL:er och laptopens egen brandvägg spelar alla roll för de anslutningar som ska lyckas. En misslyckad ping säger minst, eftersom ICMP-policyn ofta är åtskild från den TCP-policy du bryr dig om.
Skriv de reglerna mot den översatta källan, inte klientadressen. Regler knutna till adressen som aldrig syns på nätet är det vanligaste självförvållade felet i den här designen.
När VPC:n verkligen måste inleda samtalet
Om en tjänst måste meddela en arbetsstation, vänd riktningen och låt klienten hålla en varaktig utgående kanal som tjänsten svarar på. Om ett helt fjärrnätverk måste vara nåbart från VPC:n, välj en arkitektur som publicerar sina prefix och sin åtkomstpolicy i stället för att anta att Client VPN redan gör det. Klient-till-klient-åtkomst är ett tredje, snävare fall med egna rutt- och auktoriseringsobjekt. Inget av detta är en kryssruta på den befintliga slutpunkten.
Håll också omfattningen av IPv4-förklaringen ärlig. Nuvarande AWS-dokumentation skiljer ut IPv6, där den översättningen inte tillämpas, och andra anslutningsmodeller som routar annorlunda.
Testa i tre märkta steg: klienten öppnar en tillåten session, VPC-tjänsten svarar på den sessionen och en VPC-värd öppnar en ny session mot klienten. Att de två första lyckas medan den tredje misslyckas är den förväntade formen för den här designen, inte ett fel som ska jagas med brandväggsregler.