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 کا ہر ذیلی نیٹ راستہ ریسورس کے بغیر ہی قابل رسائی ہے۔ اضافی راستے peered 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 مکمل دکھائی دیتا ہے۔ گروپ کے اندر ایک اور باہر ایک صارف کے ساتھ آزمائیں۔

جب ایک سابقہ ناکام ہو، تو اس کے راستہ اندراج کا اجازت کے قاعدے سے موازنہ کریں۔ غائب اجازت اور غائب راستہ کلائنٹ لاگ میں ملتے جلتے دکھائی دیتے ہیں اور مختلف ریسورسز میں ٹھیک کیے جاتے ہیں۔