Terraform Client VPN երթուղիներ ավելի շատ CIDR-ներով, քան ենթացանցերով

Նոթբուքը միանում է Client VPN վերջնակետին, և terraform apply-ը դեռ ձախողվում է երթուղու ռեսուրսի վրա։ Կազմաձևը սովորաբար ունի ավելի շատ նպատակակետ CIDR, քան միացված ենթացանցեր, և երթուղու բլոկը թիրախ է ընտրում ինդեքսով։ Դա ենթադրում է, որ երկու հավաքածուները զուգահեռ են։ Դրանք այդպիսին չեն, և ձախողումը ի հայտ է գալիս կիրառման պահին, ոչ թե վերանայման։

Անվանեք ձախողվող օբյեկտը

Ներգրավված են երեք ռեսուրս, և յուրաքանչյուրը պատասխանում է տարբեր հարցի։ Միացումը վերջնակետի ցանցային ինտերֆեյսը տեղադրում է ենթացանցում։ Երթուղին ասում է, թե որ նպատակակետ նախածանցն է հասցվում թիրախ ենթացանցին։ Լիազորման կանոնը ասում է, թե որ օգտատերերը կարող են հասնել որ նախածանցին։ Ենթացանցին ուղղվող երթուղին, որը երբեք չի միացվել, ձախողվում է նույնիսկ երբ երկու օբյեկտներն էլ գոյություն ունեն, որովհետև թիրախը պետք է պատկանի այս վերջնակետին։

Նախ թվարկեք միացումները՝ aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0։

Հիշեք VPC-ի տեղական երթուղին

Առաջին միացումը տեղական երթուղի է ավելացնում ամբողջ VPC-ի համար, այնպես որ այդ VPC-ի յուրաքանչյուր ենթացանց արդեն հասանելի է առանց երթուղու ռեսուրսի։ Լրացուցիչ երթուղիներ կան զուգակցված VPC-ների, Transit Gateway միացումների և on-premises նախածանցների համար, որոնք VPC-ին չեն պատկանում։ Ահա թե ինչու երեք միացում ունեցող վերջնակետը կարող է օրինականորեն կրել յոթ նպատակակետ գրառում։

Նախ հաշվեք VPC-ից դուրս գտնվող նպատակակետերը, ապա ավելացրեք երթուղիներ։ Եթե այդ թիվը փոքր է CIDR ցանկից, ցանկը նկարագրում է ենթացանցեր, որոնք ընդհանրապես երթուղի չեն պահանջում։

Փոխարինեք ինդեքսը քարտեզով

Ինդեքսը մոդուլո օպերատորի մեջ փաթաթելը լռեցնում է սխալը և պահպանում մոդելավորման սխալը։ Նպատակակետը, որին հնարավոր չէ հասնել ընտրված թիրախով, դեռևս ոչ մի երթևեկություն չի կրում, որքան էլ մաքուր կիրառվի պլանը։ Փոխարենը պահեք կապը և թույլ տվեք Terraform-ին ստուգել այն որևէ բան ստեղծելուց առաջ։ Ներքևի բլոկը պատկերավոր է և օգտագործում է մատակարարի վերջնակետի երթուղու արգումենտները։

variable "client_vpn_destinations" {
  description = "Destination CIDR mapped to an associated subnet key"
  type        = map(string)
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_destinations
  client_vpn_endpoint_id = aws_ec2_client_vpn_endpoint.this.id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = aws_subnet.private[each.value].id

  lifecycle {
    precondition {
      condition     = contains(keys(aws_subnet.private), each.value)
      error_message = "Route target must be a subnet key in the associated map."
    }
  }
}

Երբ քարտեզը միացումների ցանկի կողքին է, նպատակակետ ավելացնելը պարտադրում է որոշում, թե որ ենթացանցն է այն կրում։ Դա այն զրույցն է, որը ինդեքսը թաքցնում էր։

Այլ ձախողում առաջացնում է անիմաստ արժեքներ՝ ինդեքսի սխալի փոխարեն։ Ցածր մակարդակի կառուցվածք փոխանցելը այնտեղ, որտեղ սպասվում է ավելի բարձր մակարդակի ինտերֆեյս, թողնում է API-ի կարդացած դաշտերը չլրացված, և ստացված CIDR-ն անօգտագործելի է։ Terraform-ը ցույց է տալիս նույն ձևը, երբ տողը հասնում է այնտեղ, որտեղ սպասվում է օբյեկտ։ Ստուգեք մատակարարի սխեման արգումենտի տեսակի համար։

Ապացուցեք դա հաճախորդից

Կիրառելուց առաջ գործարկեք terraform validate և պլան իրական վիճակի դեմ։ Այնուհետև համեմատեք վերջնակետի թիրախ ցանցերի ցանկը քարտեզի հետ՝ հաջող apply-ին վստահելու փոխարեն։

Ընդունման թեստը միացված հաճախորդն է, որը հասնում է յուրաքանչյուր նախատեսված նախածանցին։

Լիազորման կանոնն այն տեղն է, որտեղ շատ կարգավորումներ շուտ են կանգ առնում։ Այն սահմանափակված է նպատակակետ CIDR-ով և խմբով, և համապատասխան լիազորում չունեցող երթուղին ստեղծում է միացված հաճախորդ, որը չի կարող հասնել նախածանցին։ Ստուգեք երկու օբյեկտներն էլ յուրաքանչյուր նախածանցի համար, որովհետև երթուղին ստեղծող և կանոնը մոռացող apply-ը ամբողջական է թվում։ Փորձարկեք խմբի ներսում մեկ և դրսում մեկ օգտատիրոջով։

Երբ մեկ նախածանց ձախողվում է, համեմատեք նրա երթուղու գրառումը լիազորման կանոնի հետ։ Բացակայող լիազորումը և բացակայող երթուղին նման են երևում հաճախորդի մատյանում և ուղղվում են տարբեր ռեսուրսներում։