Proč AWS Client VPN zahazuje provoz bez odpovídající trasy

Koncový bod předává paket jen tehdy, když jeho směrovací tabulka pokrývá cíl. Přečtěte si trasy, deklarujte prefixy pomocí for_each, ověřte zpáteční cestu.

Client VPN přidělí klientovi adresu, handshake se dokončí a spojení přesto nikam nevede. Než sáhnete na certifikáty nebo verze klienta, podívejte se na vlastní směrovací tabulku koncového bodu. Koncový bod AWS Client VPN předává paket jen tehdy, když jedna z jeho tras pokrývá prefix cíle; pokud nic neodpovídá, paket se na koncovém bodu zahodí a cílový host nikdy neuvidí SYN.

To je rozhodnutí o předávání, ne o autentizaci. Děje se po navázání tunelu a po vyhodnocení autorizačních pravidel, a proto platný certifikát a platná skupina mohou stále dát mrtvé spojení.

Koncový bod předává jen to, co pokrývá jeho směrovací tabulka

Každá trasa je CIDR cíle plus podsíť, která má provoz přijmout. Koncový bod porovná cíl klienta s tímto seznamem, vybere odpovídající záznam a odešle paket do přidružené podsítě. Žádný záznam znamená žádný další skok.

Všimněte si, co trasa není. Není to záznam ve směrovací tabulce VPC a nic neautorizuje. Autorizační pravidla rozhodují, zda skupina smí cíl dosáhnout; trasy rozhodují, zda má koncový bod kam paket poslat. Obě se musí shodovat a selhávají s různými příznaky, takže hádání, které je rozbité, ztratí celé odpoledne.

Klasický nesoulad je peered VPC. Někdo přidá trasu pro 10.20.0.0/24, zatímco host žije v 10.20.4.0/24, takže adresa padá mimo každý záznam. Zachycení na straně klienta ukazuje opakované SYN bez odpovědi a logy cíle neukazují vůbec nic.

Přečtěte si seznam tras dřív než certifikát

Trasy koncového bodu jsou samostatný objekt, proto se jich ptejte přímo, místo abyste četli tabulku VPC:

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

Vezměte přesnou adresu a délku prefixu od selhávajícího klienta a pak zkontrolujte pokrytí znak po znaku. Platí shoda nejdelšího prefixu, takže širší trasa vás nezachrání, když užší míří jinam.

Jeden prostředek na cíl pomocí for_each

Ručně psané bloky tras se rozjedou ve chvíli, kdy někdo přidá prefix v konzoli. Udržujte cíle v mapě a vytvářejte jeden prostředek na klíč, aby každé přidání nebo odebrání zůstalo izolované.

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

Zachovejte závislost na síťové asociaci. Trasa potřebuje přidruženou podsíť, takže apply, který vytváří obojí, musí asociaci seřadit první, a bez tohoto odkazu si Terraform může trasu zkusit první. Pak si přečtěte plán: počet přidání tras má odpovídat prefixům, které jste přidali. Pokud plán také nahrazuje koncový bod, je prostředek koncového bodu napsaný špatně a jeho aplikace odpojí každého připojeného klienta.

Převzetí koncového bodu, který jste nevytvořili

Většina týmů dědí koncový bod postavený v konzoli, a proto neexistuje žádný kód tras. Nestavte druhý koncový bod jen proto, abyste dostali trasy do Terraformu.

Místo toho importujte, nebo předejte id jako proměnné a nechte zděděné objekty nespravované. Import potřebuje formát identifikátoru, který poskytovatel dokumentuje pro každý typ prostředku; ten kóduje koncový bod, prefix cíle a cílovou podsíť. Zkopírujte ten řetězec z dokumentace prostředku, místo abyste ho skládali z paměti, spusťte plán a než něco nového přidáte, očekávejte žádné změny.

Sledujte paket v pořadí, v jakém putuje

Když trasa existuje a spojení stále selhává, projděte cestu po pořádku, místo abyste hádali na horní vrstvě.

  1. Trasa: prefix pokrývá cíl a míří na podsíť přidruženou ke koncovému bodu.
  2. Autorizace: autorizační pravidlo povoluje tento cíl pro skupinu uživatele. Samotná trasa nikdy přístup neudělí.
  3. Zpáteční cesta: směrovací tabulka cílové podsítě posílá odpovědi zpět ke koncovému bodu a bezpečnostní skupina povoluje port z fondu adres klienta.
  4. Aplikace: otevřete skutečné TCP spojení z klienta a poté potvrďte, že logy cíle ukazují očekávanou zdrojovou adresu z fondu.

Měňte jeden prefix na apply, poté znovu přečtěte seznam tras a zaznamenejte cíl, autorizující pravidlo a zpáteční cestu společně. Další člověk, který bude ladit odmítnuté spojení, má začít od tohoto soupisu, ne od teorie o certifikátech.

Související články