Kial AWS Client VPN forĵetas trafikon sen kongrua vojo

La finpunkto plusendas paketon nur kiam ĝia vojara tabelo kovras la celon. Legu la vojojn, deklaru prefiksojn per for_each, kontrolu la revenan vojon.

Client VPN donas al la kliento adreson, la manpremo finiĝas, kaj la konekto tamen iras nien. Antaŭ ol tuŝi atestilojn aŭ klientajn versiojn, rigardu la propran vojaran tabelon de la finpunkto. AWS Client VPN finpunkto plusendas paketon nur kiam unu el ĝiaj vojoj kovras la celan prefikson; se nenio kongruas, la paketo estas forĵetata ĉe la finpunkto kaj la cela gastiganto neniam vidas SYN.

Tio estas plusenda decido, ne aŭtentiga. Ĝi okazas post kiam la tunelo staras kaj post kiam la rajtigaj reguloj estas taksitaj, tial valida atestilo kaj valida grupo ankoraŭ povas produkti mortan konekton.

La finpunkto plusendas nur tion, kion kovras ĝia vojara tabelo

Ĉiu vojo estas cela CIDR plus la subreto, kiu devas ricevi la trafikon. La finpunkto komparas la celon de la kliento kun tiu listo, elektas la kongruan eron kaj sendas la paketon en la asociitan subreton. Neniu ero signifas neniun sekvan salton.

Rimarku, kio la vojo ne estas. Ĝi ne estas ero en la vojara tabelo de la VPC, kaj ĝi rajtigas nenion. Rajtigaj reguloj decidas ĉu grupo rajtas atingi celon; vojoj decidas ĉu la finpunkto havas kien sendi la paketon. Ambaŭ devas kongrui, kaj ili fiaskas per malsamaj simptomoj, do diveni, kiu estas rompita, malŝparas posttagmezon.

La klasika malkongruo estas kunligita VPC. Iu aldonas vojon por 10.20.0.0/24 dum la gastiganto loĝas en 10.20.4.0/24, do la adreso falas ekster ĉiun eron. Klientflanka kapto montras ripetajn SYN sen respondo, kaj la protokoloj de la celo montras tute nenion.

Legu la vojliston antaŭ la atestilo

La vojoj de la finpunkto estas propra objekto, do demandu ilin rekte anstataŭ legi la tabelon de la VPC:

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

Prenu la precizan adreson kaj prefiksan longon de la fiaskanta kliento, poste kontrolu la kovron signon post signo. Validas kongruo de la plej longa prefikso, do pli larĝa vojo ne savas vin kiam pli mallarĝa montras aliloken.

Unu rimedo por celo kun for_each

Manskribitaj vojaj blokoj drivas en la momento, kiam iu aldonas prefikson en la konzolo. Tenu la celojn en mapo kaj kreu unu rimedon por ŝlosilo, por ke ĉiu aldono aŭ forigo restu izolita.

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

Konservu la dependon de la reta asocio. Vojo bezonas asociitan subreton, do apply, kiu kreas ambaŭ, devas ordigi la asocion unue, kaj sen tiu referenco Terraform libere povas provi la vojon unue. Poste legu la planon: la nombro de vojaj aldonoj devas kongrui kun la prefiksoj, kiujn vi aldonis. Se la plano ankaŭ anstataŭigas la finpunkton, la rimedo de la finpunkto estas malbone skribita, kaj apliki ĝin malkonektas ĉiun konektitan klienton.

Adopti finpunkton, kiun vi ne kreis

Plej multaj teamoj heredas finpunkton konstruita en la konzolo, tial neniu voja kodo ekzistas. Ne starigu duan finpunkton nur por enigi vojojn en Terraform.

Anstataŭe importu, aŭ pasigu la id-ojn kiel variablojn kaj lasu la hereditajn objektojn neadministritaj. Importo bezonas la identigan formaton, kiun la provizanto dokumentas por ĉiu rimeda tipo; ĝi kodas la finpunkton, la celan prefikson kaj la celan subreton. Kopiu tiun ĉenon el la rimeda dokumentaro anstataŭ kunmeti ĝin el memoro, rulu planon, kaj atendu neniujn ŝanĝojn antaŭ ol aldoni ion novan.

Spuru la paketon laŭ la ordo, en kiu ĝi vojaĝas

Kiam la vojo ekzistas kaj la konekto ankoraŭ fiaskas, trairu la vojon laŭorde anstataŭ diveni ĉe la supra tavolo.

  1. Vojo: prefikso kovras la celon kaj montras al subreto asociita kun la finpunkto.
  2. Rajtigo: rajtiga regulo permesas tiun celon por la grupo de la uzanto. Vojo sola neniam donas aliron.
  3. Revena vojo: la vojara tabelo de la cela subreto sendas respondojn reen al la finpunkto, kaj la sekureca grupo permesas la pordon el la adresa baseno de la kliento.
  4. Aplikaĵo: malfermu realan TCP-konekton de la kliento, poste konfirmu, ke la protokoloj de la celo montras la atendatan fontadreson el la baseno.

Ŝanĝu unu prefikson por apply, poste relegu la vojliston, kaj notu kune la celon, la rajtigan regulon kaj la revenan vojon. La sekva persono, kiu sencimigos rifuzitan konekton, devus komenci de tiu inventaro, ne de atestila teorio.

Rilataj artikoloj