AWS Client VPN منسلک ہے مگر انٹرنیٹ نہیں: راستوں کی جانچ

AWS Client VPN منسلک ہے مگر انٹرنیٹ تک رسائی نہیں؟ کلائنٹ کے راستے، اینڈ پوائنٹ کی اجازت، سب نیٹ کا اخراج اور DNS اسی ترتیب سے جانچیں۔

آپ AWS Client VPN اینڈ پوائنٹ سے منسلک ہیں، نجی سب نیٹ جواب دیتا ہے، اور پھر بھی ہر عوامی صفحہ وقت ختم ہو کر ختم ہوتا ہے۔ یہ امتزاج مسئلے کو زیرِ انتظام جانب کی تین چیزوں میں سے ایک تک محدود کرتا ہے: وہ راستہ جو کلائنٹ نصب کرتا ہے، اینڈ پوائنٹ کا راستہ اس کے اجازت کے قاعدے کے ساتھ، یا منسلک سب نیٹ کی اگلی چھلانگ۔ میں انہیں اسی ترتیب سے جانچتا ہوں، کیونکہ ہر ناکامی کلائنٹ کی طرف سے مختلف دکھائی دیتی ہے۔ یہ رہنما VPC سے منسلک زیرِ انتظام اینڈ پوائنٹ کے لیے ہے، EC2 انسٹانس پر OpenVPN سرور یا Cloud WAN یا Transit Gateway کنکشن کے لیے نہیں۔

کلائنٹ واقعی کس چیز کو راستہ دیتا ہے، وہیں سے شروع کریں

منسلک حالت صرف TLS سیشن اور کلائنٹ کو CIDR کی تقسیم ثابت کرتی ہے، اس سے زیادہ کچھ نہیں. ٹنل کھلا ہونے پر عوامی پتہ کہاں جائے گا، یہ آپریٹنگ سسٹم سے پوچھیں۔ Linux پر ip route get 1.1.1.1 ٹنل انٹرفیس کا نام بتانا چاہیے؛ macOS پر netstat -rn -f inet | head -5 ڈیفالٹ اندراج دکھاتا ہے؛ Windows پر Find-NetRoute -RemoteIPAddress 1.1.1.1 منتخب انٹرفیس اور اگلی چھلانگ چھاپتا ہے۔

پھر split-tunnel جھنڈا پڑھیں، کیونکہ یہ طے کرتا ہے کہ اینڈ پوائنٹ کے شائع کردہ راستے ہی وہ واحد منزلیں ہیں جو کلائنٹ ٹنل میں بھیجتا ہے:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

جب SplitTunnel true ہو، عوامی منزل ٹنل استعمال کرتی ہے صرف جب اینڈ پوائنٹ ایسا راستہ شائع کرے جو اسے ڈھانپتا ہو، اس لیے غائب 0.0.0.0/0 وہ ٹریفک مقامی انٹرفیس پر چھوڑ دیتا ہے۔ اگر یہ false ہو، کلائنٹ ٹریفک پکڑ لیتا ہے، مگر اینڈ پوائنٹ کو پھر بھی راستہ دینا اور اجازت دینی ہوتی ہے؛ ورنہ پیکٹ ٹنل میں داخل ہو کر وہیں رک جاتے ہیں۔ دونوں میں سے کوئی ترتیب بدلنے کے بعد کلائنٹ کو دوبارہ منسلک کریں، کیونکہ راستے اور DNS سرور کنکشن کے وقت ہی دیے جاتے ہیں اور چلتا ہوا کلائنٹ پرانا مجموعہ رکھ سکتا ہے۔

اینڈ پوائنٹ کا راستہ اور اجازت کا قاعدہ الگ الگ پڑھیں

یہ دو چیزیں ہیں، اور ایک بنانے سے دوسری نہیں بنتی۔ اینڈ پوائنٹ کے راستے فہرست کریں اور ایسا ڈیفالٹ راستہ تلاش کریں جس کا ہدف منسلک سب نیٹ ہو:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

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

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

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC CIDR کے لیے قاعدہ 0.0.0.0/0 کے بارے میں کچھ نہیں کہتا۔ مکمل ٹنل کے لیے غائب حصے شامل کرنے کا مطلب ہر منسلک سب نیٹ کے لیے ایک راستہ اور بعد میں جانچنے کے قابل ایک اجازت قاعدہ ہے:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all اینڈ پوائنٹ کے ہر کلائنٹ کو منزل دیتا ہے، اس لیے اسے صرف تب تک رکھیں جب تک ٹنل مکمل ہونا ہے؛ جب باندھنے کے لیے گروپ ہوں تو ڈائریکٹری گروپ سے بندھا قاعدہ بہتر ہے۔

پیکٹ کو منسلک سب نیٹ سے باہر تک لے جائیں

اینڈ پوائنٹ کا راستہ طے کرتا ہے کہ AWS وہ پیکٹ اسی سب نیٹ کو دیتا ہے۔ یہ اس کے بعد کی اگلی چھلانگ طے نہیں کرتا، وہ سب نیٹ کی اپنی VPC راستہ جدول میں رہتی ہے:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

قابلِ استعمال ڈیفالٹ راستہ عوامی سب نیٹ کے لیے انٹرنیٹ گیٹ وے کی طرف، یا نجی کے لیے NAT گیٹ وے کی طرف اشارہ کرتا ہے، اور blackhole حالت کا مطلب ہے کہ ہدف حذف ہو چکا ہے اور راستہ اب خاموشی سے مر رہا ہے۔ یہ اینڈ پوائنٹ کی راستہ فہرست سے مختلف جدول ہیں، اور ایک کی مرمت دوسرے کی مرمت نہیں کرتی۔

اس چھلانگ پر دو فلٹر بیٹھے ہیں۔ ہدف نیٹ ورک منسلکات پر لاگو سیکیورٹی گروپ کو عوامی منزل کی طرف جانے والی آؤٹ باؤنڈ ٹریفک کی اجازت دینی چاہیے، اور کوئی بھی قابلِ اطلاق نیٹ ورک ACL درخواست اور مختصرالمیعاد پورٹس پر واپسی ٹریفک کی اجازت دے۔ محدود کرنے والا منسلکات سیکیورٹی گروپ ایک عام وجہ ہے کہ نجی رسائی چلتی ہے مگر عوامی نہیں۔

تینوں کو ایک ساتھ بدلنے کے بجائے علامت سے پہلی تہہ منتخب کریں:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

DNS ناکامی کو مردہ راستے سے الگ کریں

نام کا حل آگے بھیجنے سے مختلف انداز میں ناکام ہوتا ہے، اور مکمل ٹنل اس فرق کو اہم بناتی ہے کیونکہ دھکیلے گئے حل کنندہ تک اب ٹنل کے ذریعے پہنچا جاتا ہے۔ اگر اینڈ پوائنٹ VPC DNS سرور بتائے، تو ان کے پتوں کو بھی کسی بھی دوسری منزل کی طرح راستے کی احاطے اور اجازت چاہیے۔ کون سی ناکامی ہے یہ دیکھنے کے لیے حل کنندہ سے براہِ راست پوچھیں: dig +short example.com @10.0.0.2، یا nslookup example.com 10.0.0.2 Windows پر۔

جب عددی URL جواب دے اور نام والا نہ دے، تو ڈیفالٹ راستہ ترمیم کرنا بند کریں اور DNS پر کام کریں۔ IP پتے پر درخواست نام والے مجازی میزبان اور اس کے سرٹیفکیٹ کے بارے میں کچھ ثابت نہیں کرتی، اس لیے آخری جانچ میں ایک نام والا امتحان رکھیں۔

وقت مدد کرتا ہے۔ چند سیکنڈ میں جواب نہ پانے والا TCP کنکشن راستہ بندی یا فلٹر کی طرف اشارہ کرتا ہے، جبکہ نام کی تلاش میں لٹکا رہنے والا درخواست حل کنندہ کی طرف۔ حل کنندہ ناقابلِ رسائی ہونے پر ڈیفالٹ راستہ بدلنا عموماً ایک ناکامی کو دو بنا دیتا ہے۔

صاف طریقے سے واپس لائیں، پھر اخراج کا راستہ تصدیق کریں

دونوں چیزیں اضافی نوعیت کی تھیں، اس لیے واپس لینا مرمت نہیں، حذف کرنا ہے:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

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

مختصر فہرست کے ساتھ ختم کریں اور آخری شے کو دستاویز نہیں، تبدیلی کا حصہ سمجھیں:

  • ہر منسلک سب نیٹ کے لیے ایک 0.0.0.0/0 اینڈ پوائنٹ راستہ۔
  • ان کلائنٹس کے لیے 0.0.0.0/0 ڈھانپنے والا اجازت قاعدہ جن کی آپ خدمت کرنا چاہتے ہیں۔
  • ہر منسلک سب نیٹ پر blackhole نہ ہونے والا VPC ڈیفالٹ راستہ۔
  • منسلکات سیکیورٹی گروپ کا اخراج، نیز ACL واپسی ٹریفک۔
  • حل کنندہ کے پتے راستہ دیے گئے اور اجازت یافتہ، نام والی درخواست سے تصدیق شدہ۔
  • راستے اور قاعدے کے لیے درج واپسی۔

دائرہ کار کا ایک نوٹ: یہ IPv4 راستہ ہے۔ دوہرے اسٹیک والا کلائنٹ اپنی موجودہ IPv6 رابطہ کاری برقرار رکھتا ہے، اس لیے IPv6 ڈیفالٹ راستہ اس کا ضمنی اثر نہیں، اپنی اجازت کے ساتھ الگ فیصلہ ہے۔

متعلقہ مضامین