Waarom AWS Client VPN verkeer laat vallen zonder passende route

Het eindpunt stuurt een pakket alleen door als de routetabel de bestemming dekt. Lees de routes, declareer prefixen met for_each, controleer de terugweg.

Client VPN geeft de client een adres, de handshake rondt af, en de verbinding komt nog steeds nergens. Voordat je certificaten of clientversies aanraakt, kijk je naar de routetabel van het eindpunt zelf. Een AWS Client VPN-eindpunt stuurt een pakket alleen door als een van zijn routes het bestemmingsprefix dekt; als niets past, wordt het pakket bij het eindpunt weggegooid en de doelserver ziet nooit een SYN.

Dat is een doorstuur beslissing, geen authenticatiebeslissing. Hij valt nadat de tunnel staat en nadat de autorisatieregels zijn geëvalueerd, daarom kunnen een geldig certificaat en een geldige groep toch een dode verbinding opleveren.

Het eindpunt stuurt alleen door wat de routetabel dekt

Elke route is een bestemmings-CIDR plus het subnet dat het verkeer moet ontvangen. Het eindpunt vergelijkt de bestemming van de client met die lijst, kiest de passende vermelding en stuurt het pakket naar het gekoppelde subnet. Geen vermelding betekent geen volgende hop.

Let op wat de route niet is. Het is geen vermelding in de routetabel van de VPC, en het autoriseert niets. Autorisatieregels bepalen of een groep een bestemming mag bereiken; routes bepalen of het eindpunt ergens heeft om het pakket heen te sturen. Beide moeten kloppen, en ze falen met verschillende symptomen, dus raden welke kapot is kost een middag.

De klassieke mismatch is een gepeerde VPC. Iemand voegt een route voor 10.20.0.0/24 toe terwijl de host in 10.20.4.0/24 woont, dus het adres valt buiten elke vermelding. Een opname aan de clientkant toont herhaalde SYN's zonder antwoord, en de logs van het doel tonen helemaal niets.

Lees de routelijst voor het certificaat

De routes van het eindpunt zijn een eigen object, dus vraag ze rechtstreeks op in plaats van de VPC-tabel te lezen:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

Neem het exacte adres en de prefixlengte van de falende client, en controleer dan de dekking teken voor teken. Langste-prefix-overeenkomst geldt, dus een bredere route redt je niet als een smallere ergens anders heen wijst.

Eén resource per bestemming met for_each

Handgeschreven routeblokken lopen weg op het moment dat iemand een prefix in de console toevoegt. Houd de bestemmingen in een map en maak één resource per sleutel, zodat elke toevoeging of verwijdering geïsoleerd blijft.

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

Behoud de afhankelijkheid van de netwerkkoppeling. Een route heeft een gekoppeld subnet nodig, dus een apply die beide maakt moet de koppeling eerst ordenen, en zonder die verwijzing mag Terraform de route eerst proberen. Lees daarna de planning: het aantal routetoevoegingen moet overeenkomen met de prefixen die je hebt toegevoegd. Als de planning ook het eindpunt vervangt, is de eindpuntresource verkeerd geschreven, en het toepassen ervan verbreekt elke verbonden client.

Een eindpunt overnemen dat je niet hebt gemaakt

De meeste teams erven een eindpunt dat in de console is gebouwd, daarom bestaat er geen routecode. Zet geen tweede eindpunt op alleen om routes in Terraform te krijgen.

Importeer in plaats daarvan, of geef de id's als variabelen door en laat de geërfde objecten onbeheerd. Import vereist het id-formaat dat de provider per resourcetype documenteert; het codeert het eindpunt, het bestemmingsprefix en het doelsubnet. Kopieer die string uit de resourcedocumentatie in plaats van hem uit je hoofd samen te stellen, draai een planning en verwacht geen wijzigingen voordat je iets nieuws toevoegt.

Volg het pakket in de volgorde waarin het reist

Als de route bestaat en de verbinding toch faalt, loop het pad dan in volgorde af in plaats van op de bovenste laag te raden.

  1. Route: een prefix dekt de bestemming en wijst naar een subnet dat aan het eindpunt is gekoppeld.
  2. Autorisatie: een autorisatieregel staat die bestemming toe voor de groep van de gebruiker. Een route alleen geeft nooit toegang.
  3. Terugweg: de routetabel van het doelsubnet stuurt antwoorden terug naar het eindpunt, en de beveiligingsgroep staat de poort vanuit de adrespool van de client toe.
  4. Applicatie: open een echte TCP-verbinding vanaf de client en bevestig daarna dat de logs van het doel het verwachte bronadres uit de pool tonen.

Wijzig één prefix per apply, lees daarna de routelijst opnieuw en noteer de bestemming, de autoriserende regel en de terugweg samen. De volgende persoon die een geweigerde verbinding debugt, moet bij die inventaris beginnen, niet bij een certificaattheorie.

Gerelateerde artikelen