AWS Client VPN مطابق روٹ کے بغیر ٹریفک کیوں گرا دیتا ہے

Client VPN کلائنٹ کو پتہ دیتا ہے، مصافحہ مکمل ہوتا ہے، اور کنکشن پھر بھی کہیں نہیں پہنچتا۔ سرٹیفکیٹس یا کلائنٹ ورژنز کو چھونے سے پہلے اینڈ پوائنٹ کی اپنی روٹ ٹیبل دیکھیں۔ AWS Client VPN اینڈ پوائنٹ پیکٹ صرف اسی وقت آگے بھیجتا ہے جب اس کے روٹس میں سے کوئی منزل کے سابقے کو ڈھانپ لے؛ اگر کچھ بھی مطابق نہ ہو تو پیکٹ اینڈ پوائنٹ پر ہی گرا دیا جاتا ہے اور ہدف ہوسٹ کو کبھی SYN نظر نہیں آتا۔

یہ آگے بھیجنے کا فیصلہ ہے، توثیق کا نہیں۔ یہ ٹنل کھڑی ہونے کے بعد اور اجازت کے قواعد جانچنے کے بعد ہوتا ہے، اس لیے درست سرٹیفکیٹ اور درست گروپ بھی مردہ کنکشن دے سکتے ہیں۔

اینڈ پوائنٹ صرف وہی آگے بھیجتا ہے جو اس کی روٹ ٹیبل ڈھانپتی ہے

ہر روٹ ایک منزل CIDR اور وہ سب نیٹ ہے جسے ٹریفک ملنا چاہیے۔ اینڈ پوائنٹ کلائنٹ کی منزل کا اس فہرست سے موازنہ کرتا ہے، مطابق اندراج چنتا ہے اور پیکٹ متعلقہ سب نیٹ میں بھیجتا ہے۔ اندراج نہ ہو تو اگلی چھلانگ بھی نہیں۔

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

عام عدم مطابقت peered VPC ہے۔ کوئی 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 میں لانے کے لیے دوسرا اینڈ پوائنٹ نہ کھڑا کریں۔

اس کے بجائے درآمد کریں، یا ids کو متغیر کے طور پر بھیجیں اور ورثے میں ملے آبجیکٹ بغیر انتظام چھوڑ دیں۔ درآمد کے لیے ہر وسیلہ قسم کا وہ شناختی فارمیٹ درکار ہے جو فراہم کنندہ دستاویز کرتا ہے؛ وہ اینڈ پوائنٹ، منزل کا سابقہ اور ہدف سب نیٹ انکوڈ کرتا ہے۔ وہ سٹرنگ یاد سے بنانے کے بجائے وسیلہ دستاویزات سے نقل کریں، پلان چلائیں، اور کچھ نیا شامل کرنے سے پہلے کوئی تبدیلی نہ ہونے کی توقع رکھیں۔

پیکٹ کا اسی ترتیب میں پیچھا کریں جس میں وہ سفر کرتا ہے

جب روٹ موجود ہو اور کنکشن پھر بھی ناکام ہو تو اوپری پرت پر اندازہ لگانے کے بجائے راستہ ترتیب سے چلیں۔

1. روٹ: سابقہ منزل کو ڈھانپتا ہے اور اینڈ پوائنٹ سے منسلک سب نیٹ کی طرف اشارہ کرتا ہے۔
2. اجازت: اجازت کا قاعدہ صارف کے گروپ کے لیے اس منزل کی اجازت دیتا ہے۔ صرف روٹ کبھی رسائی نہیں دیتا۔
3. واپسی کا راستہ: ہدف سب نیٹ کی روٹ ٹیبل جوابات اینڈ پوائنٹ کی طرف واپس بھیجتی ہے، اور سیکیورٹی گروپ کلائنٹ پتہ پول سے پورٹ کی اجازت دیتا ہے۔
4. ایپلیکیشن: کلائنٹ سے حقیقی TCP کنکشن کھولیں، پھر تصدیق کریں کہ ہدف کے لاگز پول سے متوقع ماخذ پتہ دکھاتے ہیں۔

ہر apply میں ایک سابقہ بدلیں، پھر روٹ کی فہرست دوبارہ پڑھیں، اور منزل، اجازت دینے والا قاعدہ اور واپسی کا راستہ اکٹھے درج کریں۔ مسترد شدہ کنکشن کو ڈیبگ کرنے والے اگلے شخص کو سرٹیفکیٹ کے نظریے سے نہیں، اسی فہرست سے شروع کرنا چاہیے۔