เส้นทาง 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 ที่สร้างเส้นทางและลืมกฎดูเหมือนสมบูรณ์ ทดสอบกับผู้ใช้หนึ่งคนในกลุ่มและหนึ่งคนนอกกลุ่ม

เมื่อเพรฟิกซ์หนึ่งล้มเหลว ให้เปรียบเทียบรายการเส้นทางกับกฎการอนุญาต การอนุญาตที่หายไปและเส้นทางที่หายไปดูคล้ายกันในบันทึกไคลเอนต์และแก้ไขในทรัพยากรที่ต่างกัน