AWS Client VPN verbonden maar geen internet: routes controleren

U bent verbonden met het endpoint van AWS Client VPN, het privé-subnet antwoordt, en toch lopen alle openbare pagina's in een time-out. Die combinatie beperkt het probleem tot een van drie objecten aan de beheerde kant: de route die de client installeert, de route van het endpoint samen met de bijbehorende autorisatieregel, of de volgende hop van het gekoppelde subnet. Ik controleer ze in die volgorde, omdat elke fout er vanaf de client anders uitziet. Deze handleiding behandelt het beheerde endpoint dat aan een VPC is gekoppeld, niet een OpenVPN-server op een EC2-instantie en niet een Cloud WAN- of Transit Gateway-koppeling.

Begin met wat de client werkelijk routeert

Een verbonden status bewijst de TLS-sessie en de CIDR-toewijzing aan de client, niets meer. Vraag het besturingssysteem waar een openbaar adres naartoe zou gaan terwijl de tunnel actief is. Op Linux zou ip route get 1.1.1.1 de tunnelinterface moeten noemen; op macOS toont netstat -rn -f inet | head -5 de standaardvermelding; op Windows drukt Find-NetRoute -RemoteIPAddress 1.1.1.1 de gekozen interface en de volgende hop af.

Lees daarna de split-tunnel-vlag, want die bepaalt of de gepubliceerde routes van het endpoint de enige bestemmingen zijn die de client de tunnel in stuurt:

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

Als SplitTunnel true is, gebruikt een openbare bestemming de tunnel alleen wanneer het endpoint een route publiceert die die bestemming dekt, dus een ontbrekende 0.0.0.0/0 laat dat verkeer op de lokale interface. Als het false is, onderschept de client het verkeer, maar het endpoint moet het nog steeds routeren en autoriseren; anders gaan pakketten de tunnel in en stoppen daar. Verbind de client opnieuw na het wijzigen van een van beide instellingen, want routes en DNS-servers worden bij het verbinden geleverd en een draaiende client kan zijn oude set behouden.

Lees de route van het endpoint en de autorisatieregel apart

Dat zijn twee objecten, en het ene aanmaken maakt het andere niet. Vermeld de routes van het endpoint en zoek een standaardroute waarvan het doel een gekoppeld subnet is:

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

Elke route heeft precies één doelsubnet, dus drie koppelingen hebben elk een bijpassende standaardroute nodig. AWS documenteert deze dekkingsvereiste, en het praktische symptoom van een gat is een gebruiker die vanuit het ene subnet werkt en vanuit het andere vastloopt, wat als een periodieke storing wordt gelezen in plaats van een ontbrekende route. De officiële documentatie over het Client VPN-scenario beschrijft de openbare-subnetopstelling waartoe deze routes behoren.

Autorisatie is het tweede object. Als geen regel de openbare bestemming dekt, draagt de tunnel het pakket en de dienst gooit het weg, dus privéresources blijven werken terwijl internet dat niet doet:

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

Een regel voor de CIDR van de VPC zegt niets over 0.0.0.0/0. De ontbrekende onderdelen voor een volledige tunnel toevoegen betekent één route per gekoppeld subnet plus een autorisatieregel die u later kunt controleren:

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 verleent de bestemming aan elke client van het endpoint, dus houd die alleen zolang de tunnel volledig moet zijn; een regel die aan een adreslijstgroep is gebonden, heeft de voorkeur wanneer u groepen hebt om aan te binden.

Volg het pakket het gekoppelde subnet uit

De route van het endpoint bepaalt dat AWS het pakket aan dat subnet geeft. Die bepaalt niet de volgende hop daarna, die in de eigen VPC-routetabel van het subnet staat:

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

Een bruikbare standaardroute wijst naar een internetgateway voor een openbaar subnet, of naar een NAT-gateway voor een privé-subnet, en een status blackhole betekent dat het doel is verwijderd en het pad nu stil sterft. Dit zijn andere tabellen dan de routelijst van het endpoint, en het ene repareren repareert het andere niet.

Op deze hop zitten twee filters. De beveiligingsgroep die op de doelnetwerkkoppeling is toegepast, moet uitgaand verkeer naar de openbare bestemming toestaan, en elke toepasselijke netwerk-ACL moet het verzoek en het retourverkeer op efemere poorten toestaan. Een beperkende koppelingsbeveiligingsgroep is een veelvoorkomende reden dat privétoegang werkt en openbare toegang niet.

Kies de eerste laag op basis van het symptoom in plaats van alle drie tegelijk te wijzigen:

Scheid een DNS-fout van een dode route

Naamresolutie faalt anders dan doorsturen, en een volledige tunnel maakt het verschil belangrijk omdat de opgedrongen resolver nu via de tunnel wordt bereikt. Als het endpoint VPC-DNS-servers opgeeft, hebben hun adressen routedekking en autorisatie nodig zoals elke andere bestemming. Vraag het de resolver rechtstreeks om te zien welke fout u hebt: dig +short example.com @10.0.0.2, of nslookup example.com 10.0.0.2 op Windows.

Als een numerieke URL antwoordt en een met naam niet, stop dan met het bewerken van de standaardroute en werk aan DNS. Een verzoek naar een IP-adres bewijst niets over een met naam aangeduide virtuele host en het certificaat daarvan, dus houd één test met naam in de eindcontrole.

Timing helpt. Een TCP-verbinding die binnen enkele seconden geen antwoord krijgt, wijst op routing of een filter, terwijl een verzoek dat in de naamopzoeking blijft hangen op de resolver wijst. De standaardroute wijzigen terwijl de resolver onbereikbaar is, maakt van één fout meestal twee.

Draai schoon terug en verifieer daarna het uitgangspad

Beide objecten waren additief, dus terugdraaien is verwijderen en geen reparatie:

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

Verbind opnieuw en bevestig via welk pad het verkeer naar buiten gaat. Vergelijk het waargenomen openbare adres met het elastische IP-adres van de NAT-gateway, of met de internetgateway die u wilde gebruiken, en controleer of een privéresource in dezelfde sessie nog antwoordt.

Sluit af met een korte lijst en behandel het laatste punt als onderdeel van de wijziging en niet als documentatie:

• Eén 0.0.0.0/0 endpointroute voor elk gekoppeld subnet.
• Een autorisatieregel die 0.0.0.0/0 dekt voor de clients die u wilt bedienen.
• Een VPC-standaardroute die niet in de status blackhole verkeert, op elk gekoppeld subnet.
• Uitgaand verkeer van de koppelingsbeveiligingsgroep, plus ACL-retourverkeer.
• Resolveradressen gerouteerd en geautoriseerd, geverifieerd met een verzoek met naam.
• Een vastgelegde terugdraai voor de route en de regel.

Een opmerking over de reikwijdte: dit is een IPv4-pad. Een dual-stackclient behoudt de IPv6-connectiviteit die hij al heeft, dus een IPv6-standaardroute is een aparte beslissing met een eigen autorisatie en geen bijeffect van deze.