উপসেটের চেয়ে বেশি CIDR নিয়ে Terraform Client VPN রুট

একটি ল্যাপটপ Client VPN এন্ডপয়েন্টে সংযুক্ত হয়, তবুও terraform apply একটি রুট রিসোর্সে ব্যর্থ হয়। কনফিগারেশনে সাধারণত সংযুক্ত সাবনেটের চেয়ে বেশি গন্তব্য CIDR থাকে, আর রুট ব্লক ইনডেক্স দিয়ে একটি টার্গেট বেছে নেয়। তাতে ধরে নেওয়া হয় দুটি সংগ্রহ সমান্তরাল। তারা নয়, এবং ব্যর্থতা পর্যালোচনার বদলে প্রয়োগের সময়েই দেখা যায়।

ব্যর্থ হওয়া অবজেক্টের নাম দিন

তিনটি রিসোর্স জড়িত এবং প্রতিটি ভিন্ন প্রশ্নের উত্তর দেয়। অ্যাসোসিয়েশন এন্ডপয়েন্টের নেটওয়ার্ক ইন্টারফেসকে একটি সাবনেটে রাখে। রুট বলে কোন গন্তব্য প্রিফিক্স কোন টার্গেট সাবনেটে পৌঁছায়। অনুমোদন নিয়ম বলে কোন ব্যবহারকারী কোন প্রিফিক্সে পৌঁছাতে পারেন। কখনও সংযুক্ত হয়নি এমন সাবনেটের দিকে নির্দেশ করা রুট ব্যর্থ হয়, যদিও দুটি অবজেক্টই বিদ্যমান, কারণ টার্গেটকে এই এন্ডপয়েন্টের অন্তর্গত হতে হবে।

প্রথমে অ্যাসোসিয়েশনগুলো তালিকাভুক্ত করুন: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0।

VPC-র স্থানীয় রুট মনে রাখুন

প্রথম অ্যাসোসিয়েশন পুরো VPC-র জন্য একটি স্থানীয় রুট যোগ করে, তাই সেই VPC-র প্রতিটি সাবনেট রুট রিসোর্স ছাড়াই আগেই পৌঁছানোযোগ্য। peered VPC, Transit Gateway সংযুক্তি এবং VPC-র মালিকানাধীন নয় এমন on-premises প্রিফিক্সের জন্য অতিরিক্ত রুট থাকে। এই কারণেই তিনটি অ্যাসোসিয়েশনযুক্ত একটি এন্ডপয়েন্ট বৈধভাবে সাতটি গন্তব্য এন্ট্রি বহন করতে পারে।

রুট যোগ করার আগে 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 সম্পূর্ণ দেখায়। গ্রুপের ভিতরে একজন ও বাইরে একজন ব্যবহারকারী দিয়ে পরীক্ষা করুন।

একটি প্রিফিক্স ব্যর্থ হলে তার রুট এন্ট্রি অনুমোদন নিয়মের সঙ্গে তুলনা করুন। অনুপস্থিত অনুমোদন ও অনুপস্থিত রুট ক্লায়েন্ট লগে একই রকম দেখায় এবং ভিন্ন রিসোর্সে ঠিক করা হয়।