Zakaj AWS Client VPN zavrže promet brez ustrezne poti

Končna točka posreduje paket le, ko njena usmerjevalna tabela pokriva cilj. Preberite poti, deklarirajte predpone s for_each, preverite povratno pot.

Client VPN odjemalcu dodeli naslov, rokovanje se konča in povezava vseeno ne pelje nikamor. Preden se dotaknete potrdil ali različic odjemalca, poglejte lastno usmerjevalno tabelo končne točke. Končna točka AWS Client VPN posreduje paket le, ko ena od njenih poti pokriva predpono cilja; če se nič ne ujema, se paket zavrže na končni točki in ciljni gostitelj nikoli ne vidi SYN.

To je odločitev o posredovanju, ne o preverjanju pristnosti. Zgodi se po vzpostavitvi tunela in po oceni pravil za odobritev, zato lahko veljavno potrdilo in veljavna skupina še vedno ustvarita mrtvo povezavo.

Končna točka posreduje le tisto, kar pokriva njena usmerjevalna tabela

Vsaka pot je CIDR cilja plus podomrežje, ki naj bi prejelo promet. Končna točka primerja cilj odjemalca s tem seznamom, izbere ustrezni vnos in pošlje paket v povezano podomrežje. Brez vnosa ni naslednjega skoka.

Bodite pozorni, kaj pot ni. Ni vnos v usmerjevalni tabeli VPC in ničesar ne odobri. Pravila za odobritev odločajo, ali lahko skupina doseže cilj; poti odločajo, ali ima končna točka kam poslati paket. Oba se morata ujemati, in odpovedujeta z različnimi simptomi, zato ugibanje, kateri je pokvarjen, zapravi popoldne.

Klasično neskladje je VPC s peer povezavo. Nekdo doda pot za 10.20.0.0/24, medtem ko gostitelj živi v 10.20.4.0/24, zato naslov pade izven vsakega vnosa. Zajem na strani odjemalca kaže ponavljajoče se SYN brez odgovora, dnevnik cilja pa ne kaže prav ničesar.

Preberite seznam poti pred potrdilom

Poti končne točke so samostojen objekt, zato jih vprašajte neposredno, namesto da bi brali tabelo VPC:

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

Vzemite točen naslov in dolžino predpone od odjemalca, ki ne uspe, nato preverite pokritost znak za znakom. Velja ujemanje najdaljše predpone, zato širša pot ne pomaga, ko ožja kaže drugam.

En vir na cilj s for_each

Ročno napisani bloki poti se premaknejo v trenutku, ko nekdo doda predpono v konzoli. Hranite cilje v zemljevidu in ustvarite en vir na ključ, da vsako dodajanje ali odstranitev ostane izolirano.

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

Ohranite odvisnost od omrežne povezave. Pot potrebuje povezano podomrežje, zato mora apply, ki ustvari oboje, najprej urediti povezavo, in brez te reference lahko Terraform najprej poskusi pot. Nato preberite načrt: število dodanih poti se mora ujemati s predponami, ki ste jih dodali. Če načrt zamenja tudi končno točko, je vir končne točke napisan napačno, in njegova uporaba prekine vsakega povezanega odjemalca.

Prevzem končne točke, ki je niste ustvarili

Večina ekip podeduje končno točko, zgrajeno v konzoli, zato koda poti ne obstaja. Ne postavljajte druge končne točke samo zato, da bi poti prišle v Terraform.

Namesto tega uvozite, ali posredujte id-je kot spremenljivke in pustite podedovane objekte brez upravljanja. Uvoz potrebuje obliko identifikatorja, ki jo ponudnik dokumentira za vsako vrsto vira; ta kodira končno točko, predpono cilja in ciljno podomrežje. Kopirajte ta niz iz dokumentacije vira, namesto da bi ga sestavljali po spominu, zaženite načrt in pred dodajanjem česa novega pričakujte brez sprememb.

Sledite paketu v vrstnem redu, v katerem potuje

Ko pot obstaja in povezava še vedno ne uspe, prehodite pot po vrsti, namesto da bi ugibali na zgornjem sloju.

  1. Pot: predpona pokriva cilj in kaže na podomrežje, povezano s končno točko.
  2. Odobritev: pravilo za odobritev dovoli ta cilj skupini uporabnika. Sama pot nikoli ne podeli dostopa.
  3. Povratna pot: usmerjevalna tabela ciljnega podomrežja pošilja odgovore nazaj proti končni točki, varnostna skupina pa dovoli vrata iz bazena naslovov odjemalca.
  4. Aplikacija: odprite pravo TCP povezavo z odjemalca, nato potrdite, da dnevniki cilja kažejo pričakovani izvorni naslov iz bazena.

Spremenite eno predpono na apply, nato znova preberite seznam poti in skupaj zapišite cilj, pravilo, ki odobri, in povratno pot. Naslednja oseba, ki bo razhroščevala zavrnjeno povezavo, naj začne pri tem seznamu, ne pri teoriji o potrdilih.

Sorodni članki