Waarom AWS Client VPN verkeer laat val sonder 'n ooreenstemmende roete

Die eindpunt stuur 'n pakket net deur wanneer sy roetetabel die bestemming dek. Lees die roetes, verklaar voorvoegsels met for_each, verifieer die terugpad.

Client VPN gee die kliënt 'n adres, die handskud voltooi, en die verbinding gaan steeds nêrens heen nie. Voordat jy aan sertifikate of kliëntweergawes raak, kyk na die eindpunt se eie roetetabel. 'n AWS Client VPN-eindpunt stuur 'n pakket slegs deur wanneer een van sy roetes die bestemmingsvoorvoegsel dek; as niks pas nie, word die pakket by die eindpunt weggegooi en die teikenhost sien nooit 'n SYN nie.

Dit is 'n deurstuur-besluit, nie 'n verifikasiebesluit nie. Dit gebeur nadat die tonnel op is en nadat die magtigingsreëls geëvalueer is, en daarom kan 'n geldige sertifikaat en 'n geldige groep steeds 'n dooie verbinding lewer.

Die eindpunt stuur net deur wat sy roetetabel dek

Elke roete is 'n bestemmings-CIDR plus die subnet wat die verkeer moet ontvang. Die eindpunt vergelyk die kliënt se bestemming met daardie lys, kies die passende inskrywing en stuur die pakket na die geassosieerde subnet. Geen inskrywing beteken geen volgende hop.

Let op wat die roete nie is nie. Dit is nie 'n VPC-roetetabel-inskrywing nie, en dit magtig niks. Magtigingsreëls bepaal of 'n groep 'n bestemming mag bereik; roetes bepaal of die eindpunt êrens het om die pakket heen te stuur. Albei moet saamstem, en hulle faal met verskillende simptome, so om te raai watter een stukkend is, mors 'n middag.

Die klassieke wanverhouding is 'n gepeerde VPC. Iemand voeg 'n roete vir 10.20.0.0/24 by terwyl die host in 10.20.4.0/24 woon, so die adres val buite elke inskrywing. 'n Kliëntkant-opname wys herhaalde SYN's sonder antwoord, en die teiken se logs wys glad niks.

Lees die roetelys voor die sertifikaat

Die eindpunt se roetes is hul eie objek, so bevraag hulle direk in plaas daarvan om die VPC-tabel te lees:

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

Neem die presiese adres en voorvoegsellengte van die falende kliënt, en kontroleer dan dekking karakter vir karakter. Langste-voorvoegsel-passing geld, so 'n breër roete red jou nie wanneer 'n nouer een êrens anders heen wys nie.

Een hulpbron per bestemming met for_each

Handgeskrewe roeteblokke dryf die oomblik wanneer iemand 'n voorvoegsel in die konsole byvoeg. Hou die bestemmings in 'n kaart en skep een hulpbron per sleutel, sodat elke byvoeging of verwydering geïsoleer bly.

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]
}

Hou die afhanklikheid van die netwerkassosiasie. 'n Roete het 'n geassosieerde subnet nodig, so 'n apply wat albei skep, moet die assosiasie eerste orden, en sonder daardie verwysing is Terraform vry om die roete eerste te probeer. Lees dan die plan: die aantal roetebevoegings moet ooreenstem met die voorvoegsels wat jy bygevoeg het. As die plan ook die eindpunt vervang, is die eindpunt-hulpbron verkeerd geskryf, en om dit toe te pas ontkoppel elke verbonde kliënt.

Om 'n eindpunt te aanvaar wat jy nie geskep het nie

Die meeste spanne erf 'n eindpunt wat in die konsole gebou is, en daarom bestaan daar geen roetekode nie. Moet nie 'n tweede eindpunt oprig net om roetes in Terraform te kry nie.

Voer eerder in, of gee die ids as veranderlikes deur en laat die geërfde objekte onbestuur. Invoer benodig die identifiseerderformaat wat die verskaffer vir elke hulpbron-tipe dokumenteer, wat die eindpunt, die bestemmingsvoorvoegsel en die teikensubnet enkodeer. Kopieer daardie string uit die hulpbrondokumentasie eerder as om dit uit geheue saam te stel, hardloop 'n plan en verwag geen veranderinge voordat jy iets nuuts byvoeg nie.

Volg die pakket in die volgorde waarin dit reis

Wanneer die roete bestaan en die verbinding steeds faal, stap die pad in volgorde eerder as om op die boonste laag te raai.

  1. Roete: 'n voorvoegsel dek die bestemming en wys na 'n subnet wat met die eindpunt geassosieer is.
  2. Magtiging: 'n magtigingsreël laat daardie bestemming vir die gebruiker se groep toe. 'n Roete alleen gee nooit toegang nie.
  3. Terugpad: die teikensubnet se roetetabel stuur antwoorde terug na die eindpunt, en die sekuriteitsgroep laat die poort vanaf die kliënt-adrespoel toe.
  4. Toepassing: maak 'n werklike TCP-verbinding vanaf die kliënt oop, en bevestig dan dat die teiken se logs die verwagte bronadres uit die poel wys.

Verander een voorvoegsel per apply, herlees daarna die roetelys, en teken die bestemming, die magtigende reël en die terugpad saam aan. Die volgende persoon wat 'n geweierde verbinding ontfout, moet by daardie inventaris begin, nie by 'n sertifikaatteorie nie.

Verwante artikels