مسیرهای 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ی که مسیر را می‌سازد و قاعده را فراموش می‌کند، کامل به نظر می‌رسد. با یک کاربر داخل گروه و یکی بیرون از آن آزمایش کنید.

وقتی یک پیشوند شکست می‌خورد، ورودی مسیر آن را با قاعده مجوز مقایسه کنید. مجوز غایب و مسیر غایب در گزارش کلاینت شبیه به هم دیده می‌شوند و در منابع متفاوتی اصلاح می‌شوند.