ทำไม AWS Client VPN จึงทิ้งทราฟฟิกเมื่อไม่มีเส้นทางที่ตรงกัน

Client VPN มอบที่อยู่ให้ไคลเอนต์ การจับมือเสร็จสมบูรณ์ แต่การเชื่อมต่อก็ยังไปไม่ถึงไหน ก่อนจะแตะต้องใบรับรองหรือเวอร์ชันไคลเอนต์ ให้ดูตารางเส้นทางของปลายทางเอง ปลายทาง AWS Client VPN จะส่งต่อแพ็กเก็ตก็ต่อเมื่อเส้นทางเส้นใดเส้นหนึ่งครอบคลุมคำนำหน้าปลายทาง ถ้าไม่มีอะไรตรงกัน แพ็กเก็ตจะถูกทิ้งที่ปลายทาง และโฮสต์ปลายทางจะไม่เห็น SYN เลย

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

ปลายทางส่งต่อเฉพาะสิ่งที่ตารางเส้นทางของมันครอบคลุม

แต่ละเส้นทางคือ CIDR ปลายทางบวกซับเน็ตที่จะรับทราฟฟิก ปลายทางจะเทียบปลายทางของไคลเอนต์กับรายการนั้น เลือกรายการที่ตรงกัน แล้วส่งแพ็กเก็ตเข้าไปในซับเน็ตที่เชื่อมโยง ไม่มีรายการหมายถึงไม่มีฮอปถัดไป.

สังเกตว่าเส้นทางไม่ใช่อะไร มันไม่ใช่รายการในตารางเส้นทางของ VPC และไม่ได้อนุญาตอะไรเลย กฎการอนุญาตตัดสินว่ากลุ่มหนึ่งเข้าถึงปลายทางได้หรือไม่ เส้นทางตัดสินว่าปลายทางมีที่ให้ส่งแพ็กเก็ตหรือไม่ ทั้งสองอย่างต้องสอดคล้องกัน และล้มเหลวด้วยอาการต่างกัน การเดาว่าอันไหนเสียจึงเสียเวลาทั้งบ่าย

ความไม่สอดคล้องแบบคลาสสิกคือ VPC ที่ peered กัน มีคนเพิ่มเส้นทางสำหรับ 10.20.0.0/24 ขณะที่โฮสต์อยู่ใน 10.20.4.0/24 ที่อยู่จึงตกอยู่นอกทุกรายการ การดักจับฝั่งไคลเอนต์แสดง SYN ซ้ำโดยไม่มีคำตอบ และบันทึกของปลายทางไม่แสดงอะไรเลย

อ่านรายการเส้นทางก่อนใบรับรอง

เส้นทางของปลายทางเป็นออบเจ็กต์แยกต่างหาก จึงควรถามโดยตรงแทนการอ่านตารางของ VPC:

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

นำที่อยู่ที่แน่นอนและความยาวคำนำหน้าจากไคลเอนต์ที่ล้มเหลว แล้วตรวจสอบการครอบคลุมทีละอักขระ การจับคู่คำนำหน้าที่ยาวที่สุดมีผลใช้บังคับ เส้นทางที่กว้างกว่าจึงไม่ช่วยเมื่อเส้นทางที่แคบกว่าชี้ไปที่อื่น

หนึ่งทรัพยากรต่อหนึ่งปลายทางด้วย for_each

บล็อกเส้นทางที่เขียนด้วยมือจะคลาดเคลื่อนทันทีที่มีคนเพิ่มคำนำหน้าในคอนโซล เก็บปลายทางไว้ในแมปและสร้างทรัพยากรหนึ่งรายการต่อคีย์ เพื่อให้การเพิ่มหรือลบแต่ละครั้งแยกออกจากกัน

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

รักษาการพึ่งพาการเชื่อมโยงเครือข่ายไว้ เส้นทางต้องมีซับเน็ตที่เชื่อมโยงอยู่ apply ที่สร้างทั้งสองอย่างจึงต้องจัดลำดับการเชื่อมโยงก่อน และหากไม่มีข้อมูลอ้างอิงนั้น Terraform ก็มีอิสระที่จะลองเส้นทางก่อน จากนั้นอ่านแผน: จำนวนเส้นทางที่เพิ่มควรตรงกับคำนำหน้าที่คุณเพิ่ม ถ้าแผนยังแทนที่ปลายทางด้วย แสดงว่าทรัพยากรปลายทางเขียนผิด และการนำไปใช้จะตัดการเชื่อมต่อไคลเอนต์ที่เชื่อมอยู่ทุกตัว

การรับปลายทางที่คุณไม่ได้สร้าง

ทีมส่วนใหญ่ได้รับปลายทางที่สร้างในคอนโซลมาเป็นมรดก จึงไม่มีโค้ดเส้นทางเลย อย่าตั้งปลายทางที่สองเพียงเพื่อนำเส้นทางเข้า Terraform

ให้ทำการนำเข้าแทน หรือส่ง id เป็นตัวแปรและปล่อยวัตถุมรดกไว้โดยไม่จัดการ การนำเข้าต้องใช้รูปแบบตัวระบุที่ผู้ให้บริการจัดทำเอกสารไว้สำหรับทรัพยากรแต่ละชนิด ซึ่งเข้ารหัสปลายทาง คำนำหน้าปลายทาง และซับเน็ตเป้าหมาย คัดลอกสตริงนั้นจากเอกสารของทรัพยากรแทนการประกอบจากความจำ รันแผน และคาดว่าจะไม่มีการเปลี่ยนแปลงก่อนที่คุณจะเพิ่มสิ่งใหม่

ติดตามแพ็กเก็ตตามลำดับที่มันเดินทาง

เมื่อมีเส้นทางแล้วแต่การเชื่อมต่อยังล้มเหลว ให้เดินตามเส้นทางตามลำดับแทนการเดาที่ชั้นบน

1. เส้นทาง: คำนำหน้าครอบคลุมปลายทางและชี้ไปยังซับเน็ตที่เชื่อมโยงกับปลายทาง
2. การอนุญาต: กฎการอนุญาตอนุญาตปลายทางนั้นสำหรับกลุ่มของผู้ใช้ เส้นทางเพียงอย่างเดียวไม่เคยให้สิทธิ์เข้าถึง
3. เส้นทางขากลับ: ตารางเส้นทางของซับเน็ตเป้าหมายส่งคำตอบกลับมาที่ปลายทาง และกลุ่มความปลอดภัยอนุญาตพอร์ตจากพูลที่อยู่ของไคลเอนต์
4. แอปพลิเคชัน: เปิดการเชื่อมต่อ TCP จริงจากไคลเอนต์ แล้วยืนยันว่าบันทึกของปลายทางแสดงที่อยู่ต้นทางที่คาดหวังจากพูล

เปลี่ยนคำนำหน้าหนึ่งรายการต่อ apply จากนั้นอ่านรายการเส้นทางอีกครั้ง และบันทึกปลายทาง กฎที่อนุญาต และเส้นทางขากลับไว้ด้วยกัน คนถัดไปที่แก้ปัญหาการเชื่อมต่อที่ถูกปฏิเสธควรเริ่มจากรายการนี้ ไม่ใช่จากทฤษฎีเรื่องใบรับรอง