AWS Client VPN anslutet men inget internet: kontroll av rutter

Du är ansluten till AWS Client VPN-slutpunkten, det privata subnätet svarar, och ändå tar varje offentlig sida timeout. Den kombinationen begränsar problemet till ett av tre objekt på den hanterade sidan: rutten klienten installerar, slutpunktens rutt tillsammans med dess behörighetsregel, eller det associerade subnätets nästa hopp. Jag kontrollerar dem i den ordningen eftersom varje fel ser olika ut från klienten. Den här guiden täcker den VPC-associerade hanterade slutpunkten, inte en OpenVPN-server på en EC2-instans och inte en Cloud WAN- eller Transit Gateway-anslutning.

Börja med vad klienten faktiskt routar

Ett anslutet tillstånd bevisar TLS-sessionen och klientens CIDR-tilldelning, inget mer. Fråga operativsystemet vart en offentlig adress skulle gå medan tunneln är uppe. På Linux ska ip route get 1.1.1.1 namnge tunnelgränssnittet; på macOS visar netstat -rn -f inet | head -5 standardposten; på Windows skriver Find-NetRoute -RemoteIPAddress 1.1.1.1 ut det valda gränssnittet och nästa hopp.

Läs sedan split-tunnel-flaggan, eftersom den avgör om slutpunktens publicerade rutter är de enda destinationer som klienten skickar in i tunneln:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

När SplitTunnel är true använder en offentlig destination tunneln bara när slutpunkten publicerar en rutt som täcker den, så en saknad 0.0.0.0/0 lämnar trafiken på det lokala gränssnittet. När den är false fångar klienten trafiken, men slutpunkten måste fortfarande routa och auktorisera den; annars går paketen in i tunneln och stannar där. Anslut klienten igen efter att ha ändrat endera inställningen, eftersom rutter och DNS-servrar levereras vid anslutningen och en körande klient kan behålla sin gamla uppsättning.

Läs slutpunktens rutt och behörighetsregeln separat

Det är två objekt, och att skapa det ena skapar inte det andra. Lista slutpunktens rutter och leta efter en standardrutt vars mål är ett associerat subnät:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Varje rutt har exakt ett målsubnät, så tre associeringar behöver en motsvarande standardrutt var. AWS dokumenterar detta täckningskrav, och det praktiska symtomet på en lucka är en användare som arbetar från ett subnät och fastnar från ett annat, vilket läses som ett intermittent fel istället för en saknad rutt. Den officiella Client VPN-scenariodokumentationen beskriver det offentliga subnätets upplägg som dessa rutter hör till.

Auktorisering är det andra objektet. När ingen regel täcker den offentliga destinationen bär tunneln paketet och tjänsten kastar det, så privata resurser fortsätter fungera medan internet inte gör det:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

En regel för VPC-CIDR säger ingenting om 0.0.0.0/0. Att lägga till de saknade delarna för en full tunnel innebär en rutt per associerat subnät plus en behörighetsregel du kan granska senare:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all ger destinationen till varje klient på slutpunkten, så behåll den bara så länge tunneln ska vara full; en regel bunden till en kataloggrupp är att föredra när du har grupper att binda till.

Följ paketet ut ur det associerade subnätet

Slutpunktens rutt avgör att AWS lämnar paketet till det subnätet. Den avgör inte nästa hopp därefter, som bor i subnätets egen VPC-rutttabell:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

En användbar standardrutt pekar på en internetgateway för ett offentligt subnät, eller på en NAT-gateway för ett privat, och ett tillstånd av blackhole betyder att målet har raderats och att vägen nu dör tyst. Det är andra tabeller än slutpunktens ruttlista, och att reparera den ena reparerar inte den andra.

På detta hopp sitter två filter. Säkerhetsgruppen som tillämpas på mål-nätverksassociationen måste tillåta utgående trafik mot den offentliga destinationen, och varje tillämplig nätverks-ACL måste tillåta begäran och returtrafiken på efemära portar. En restriktiv associationssäkerhetsgrupp är en vanlig orsak till att privat åtkomst fungerar medan offentlig inte gör det.

Välj det första lagret utifrån symtomet istället för att ändra alla tre på en gång:

Skilj DNS-fel från en död rutt

Namnuppslagning misslyckas annorlunda än vidarebefordran, och full tunnel gör skillnaden viktig eftersom den påtvingade resolvern nu nås genom tunneln. Om slutpunkten anger VPC-DNS-servrar behöver deras adresser ruttäckning och behörighet som vilken annan destination som helst. Fråga resolvern direkt för att se vilket fel du har: dig +short example.com @10.0.0.2, eller nslookup example.com 10.0.0.2 på Windows.

När en numerisk URL svarar och en namngiven inte gör det, sluta redigera standardrutten och arbeta med DNS. En begäran till en IP-adress bevisar ingenting om en namngiven virtuell värd och dess certifikat, så behåll ett namngivet test i den avslutande kontrollen.

Timing hjälper. En TCP-anslutning som inte får svar inom några sekunder pekar på routning eller ett filter, medan en begäran som hänger i namnuppslagningen pekar på resolvern. Att ändra standardrutten medan resolvern är oåtkomlig gör oftast ett fel till två.

Rulla tillbaka rent och verifiera sedan utgångsvägen

Båda objekten var additiva, så återställning är radering och inte reparation:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Anslut igen och bekräfta vilken väg trafiken lämnar. Jämför den observerade offentliga adressen med NAT-gatewayens elastiska IP-adress eller med internetgatewayen du tänkte använda, och kontrollera att en privat resurs fortfarande svarar i samma session.

Avsluta med en kort lista och behandla den sista punkten som en del av ändringen och inte som dokumentation:

• En 0.0.0.0/0 slutpunktsrutt för varje associerat subnät.
• En behörighetsregel som täcker 0.0.0.0/0 för de klienter du vill betjäna.
• En VPC-standardrutt som inte är i tillståndet blackhole på varje associerat subnät.
• Utgående trafik från associationssäkerhetsgruppen plus ACL-returtrafik.
• Resolveradresser routade och auktoriserade, verifierade med en namngiven begäran.
• En registrerad återställning för rutten och regeln.

En notering om omfattningen: detta är en IPv4-väg. En dual-stack-klient behåller den IPv6-anslutning den redan har, så en IPv6-standardrutt är ett eget beslut med egen behörighet och inte en bieffekt av denna.