Miért dobja el az AWS Client VPN a forgalmat megfelelő útvonal nélkül

A végpont csak akkor továbbít egy csomagot, ha az útvonaltáblája lefedi a célt. Olvasd ki az útvonalakat, deklaráld a prefixeket for_each-csel, ellenőrizd a visszautat.

A Client VPN címet ad a kliensnek, a kézfogás lezajlik, és a kapcsolat mégsem vezet sehova. Mielőtt a tanúsítványokhoz vagy a kliensverziókhoz nyúlnál, nézd meg a végpont saját útvonaltábláját. Egy AWS Client VPN végpont csak akkor továbbít egy csomagot, ha az útvonalai közül valamelyik lefedi a cél prefixét; ha semmi nem illeszkedik, a csomag a végponton eldobódik, és a célgép soha nem lát SYN-t.

Ez továbbítási döntés, nem hitelesítési döntés. Azután történik, hogy az alagút felállt és a jogosultsági szabályok kiértékelődtek, ezért egy érvényes tanúsítvány és egy érvényes csoport még mindig halott kapcsolatot eredményezhet.

A végpont csak azt továbbítja, amit az útvonaltáblája lefed

Minden útvonal egy cél-CIDR és az az alhálózat, amelynek a forgalmat fogadnia kell. A végpont összeveti a kliens célját ezzel a listával, kiválasztja az illeszkedő bejegyzést, és a csomagot a kapcsolt alhálózatba küldi. Nincs bejegyzés, nincs következő ugrás.

Figyeld meg, mi nem az útvonal. Nem bejegyzés a VPC útvonaltáblájában, és nem jogosít fel semmire. A jogosultsági szabályok döntik el, elérhet-e egy csoport egy célt; az útvonalak döntenek arról, van-e a végpontnak hova küldenie a csomagot. Mindkettőnek egyeznie kell, és különböző tünetekkel hibáznak, ezért a találgatás, melyik romlott el, egy délutánt visz el.

A klasszikus eltérés egy peeringelt VPC. Valaki hozzáad egy útvonalat a 10.20.0.0/24-hez, miközben a gép a 10.20.4.0/24-ben lakik, így a cím minden bejegyzésen kívül esik. Az ügyféloldali rögzítés ismétlődő SYN-eket mutat válasz nélkül, a cél naplói pedig semmit sem mutatnak.

A tanúsítvány előtt olvasd ki az útvonallistát

A végpont útvonalai külön objektumok, ezért kérdezd le őket közvetlenül, ahelyett hogy a VPC tábláját olvasnád:

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

Vedd a hibázó kliens pontos címét és prefixhosszát, majd ellenőrizd a lefedettséget karakterről karakterre. A leghosszabb prefix egyezése érvényes, ezért egy szélesebb útvonal nem ment meg, ha egy szűkebb máshova mutat.

Egy erőforrás célonként for_each-csel

A kézzel írt útvonalblokkok abban a pillanatban elcsúsznak, amikor valaki prefixet ad hozzá a konzolon. Tartsd a célokat egy mapben, és hozz létre egy erőforrást kulcsonként, hogy minden hozzáadás vagy törlés elkülönülten maradjon.

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

Tartsd meg a hálózati hozzárendeléstől való függőséget. Egy útvonalhoz kapcsolt alhálózat kell, ezért a mindkettőt létrehozó apply-nak előre kell sorolnia a hozzárendelést, és e hivatkozás nélkül a Terraform szabadon előbb próbálhatja az útvonalat. Aztán olvasd ki a tervet: az útvonal-hozzáadások számának meg kell egyeznie a hozzáadott prefixekkel. Ha a terv a végpontot is lecseréli, a végpont erőforrása hibásan van megírva, és alkalmazása minden csatlakozott klienst leválaszt.

Egy általad nem létrehozott végpont átvétele

A legtöbb csapat konzolon épített végpontot örököl, ezért nem létezik útvonalkód. Ne állíts fel második végpontot csak azért, hogy útvonalak kerüljenek a Terraformba.

Inkább importálj, vagy add át az id-ket változóként, és hagyd az örökölt objektumokat kezeletlenül. Az importhoz minden erőforrástípusnál arra az azonosítóformátumra van szükség, amelyet a szolgáltató dokumentál; ez kódolja a végpontot, a cél prefixét és a cél alhálózatot. Másold ki ezt a karakterláncot az erőforrás dokumentációjából, ne fejből állítsd össze, futtass egy tervet, és ne számíts változásra, mielőtt valami újat hozzáadnál.

Kövesd a csomagot abban a sorrendben, ahogy halad

Ha az útvonal létezik és a kapcsolat mégis elakad, járj végig az úton sorrendben, ne a felső rétegen találgass.

  1. Útvonal: egy prefix lefedi a célt, és a végponthoz kapcsolt alhálózatra mutat.
  2. Jogosultság: egy jogosultsági szabály engedélyezi azt a célt a felhasználó csoportjának. Egyedül egy útvonal soha nem ad hozzáférést.
  3. Visszaút: a cél alhálózat útvonaltáblája visszaküldi a válaszokat a végpont felé, és a biztonsági csoport engedélyezi a portot a kliens címtartományából.
  4. Alkalmazás: nyiss valódi TCP-kapcsolatot a kliensről, majd igazold, hogy a cél naplói a tartományból várt forráscímet mutatják.

Apply-onként egy prefixet változtass, utána olvasd újra az útvonallistát, és jegyezd fel együtt a célt, a jogosító szabályt és a visszautat. A következő ember, aki egy elutasított kapcsolatot hibakeres, ebből a leltárból induljon, ne egy tanúsítványelméletből.

Kapcsolódó cikkek