AWS Client VPN اینڈ پوائنٹ کا DNS: حل شدہ IP پن کرنا کیوں ناکام ہوتا ہے
AWS Client VPN اینڈ پوائنٹ کا نام اس پتے سے بدلیں جو آپ نے حل کیا، اور ٹنل بعد میں کام کرنا بند کر دے گا۔ برآمد شدہ نام اور اس کا بے ترتیب سابقہ رکھیں۔
پچھلے ہفتے dig +short نے آپ کی AWS Client VPN پروفائل میں اینڈ پوائنٹ نام کے لیے ایک پتہ دیا، اور ٹنل جڑ گیا۔ اس ہفتے وہی پروفائل آپ کے لیپ ٹاپ پر 'Connecting' پر کھڑی ہے جبکہ ساتھی کی نہ چھی ہوئی کاپی اب بھی کام کر رہی ہے۔ کچھ بلاک نہیں ہوا اور سرٹیفکیٹ کی مدت ختم نہیں ہوئی۔ کسی نے اینڈ پوائنٹ کا ہوسٹ نام اسی حل شدہ پتے سے بدل دیا، اور سروس اب وہاں جواب نہیں دیتی۔ برآمد شدہ نام وہ حصہ ہے جو اس تبدیلی کو سہنے کے لیے بنایا گیا ہے۔
آپ کی پروفائل میں نام وہ نام نہ ہو جو پوچھا جاتا ہے
Client VPN سے برآمد ہونے والی پروفائلز میں عام طور پر remote-random-hostname ہوتا ہے۔ جب یہ آپشن فعال ہو تو کلائنٹ ایک بار استعمال ہونے والا لیبل بناتا ہے، اسے نقطے سے اینڈ پوائنٹ نام کے ساتھ جوڑتا ہے اور مجموعی نام حل کرتا ہے۔ اینڈ پوائنٹ کے زون میں وائلڈ کارڈ ریکارڈ کسی بھی لیبل کا جواب دیتا ہے، اسی لیے بناوٹی سابقہ بھی حل ہوتا ہے اور اسی لیے کوئری کو ہاتھ سے دہرانے کی کوشش میں یہ چال پوشیدہ رہتی ہے۔
لہٰذا جب آپ اینڈ پوائنٹ نام ٹرمینل میں چسپاں کر کے جواب پاتے ہیں، تو آپ نے اس نام سے مختلف نام حل کیا ہے جو کلائنٹ جڑتے وقت استعمال کرتا ہے۔ یہ فرق پروفائل میں درست کرنے والا نقص نہیں ہے۔ لیبل جان بوجھ کر دوبارہ بنایا جاتا ہے: یہ آپشن کیش کو پرانا جواب رکھنے سے روکتا ہے، اور یہ کبھی آپ کی مشین یا سیشن کی شناخت نہیں کرتا۔
مجھے وہ مطابقت کی حالت ملی ہے جہاں کلائنٹ اس آپشن کو بالکل نظر انداز کرتا ہے۔ AWS اس کا حل درج کرتا ہے: اصل اینڈ پوائنٹ نام رکھیں اور آگے ایک بے ترتیب سٹرنگ اور نقطہ شامل کریں، اسے چسپاں کرنے کی قدر کے بجائے نام رکھنے کا نمونہ سمجھیں۔ اسے پرانے کلائنٹ پر لاگو کرنا معقول ہے؛ سابقے والی سٹرنگ کو اینڈ پوائنٹ کے طور پر ہارڈ کوڈ کرنا نہیں۔
محفوظ جواب درست کیوں نہیں رہ سکتا
Client VPN اینڈ پوائنٹ پتے AWS سنبھالتا ہے اور وہ وقت کے ساتھ بدلتے ہیں، جو بہترین طریقوں کی دستاویز صریحاً کہتی ہے۔ پکڑا گیا جواب ایک حل کی تصویر ہے۔ اسے ہارڈ کوڈ کرنے والی پروفائل سروس کے ہلتے ہی ریٹائر شدہ ہوسٹ کی طرف نشانہ بنی پروفائل بن جاتی ہے، اور ناکامی شاذ و نادر ہی DNS جیسی لگتی ہے: آپ کو کنکشن ٹائم آؤٹ یا رکا ہوا ہینڈ شیک ملتا ہے، اس لیے لوگ روٹنگ اور سرٹیفکیٹ کے پیچھے بھاگتے ہیں۔
/etc/hosts میں وہی جواب وہی مدت ایک اضافی مسئلے کے ساتھ وراثت میں لیتا ہے۔ hosts اندراج ری بوٹ، دوبارہ برآمد اور 'کلائنٹ دوبارہ انسٹال کریں' کی مرمت سے بچ جاتا ہے، اس لیے پتہ ہلنے پر ہر بار ناکامی لوٹ آتی ہے۔ میں نے ایک کو ہفتوں بے ضرر پڑا دیکھا، پھر اسے اٹھانے والی ہر مشین کو بند کرتے دیکھا، جبکہ نئی تنصیبات معمول کے مطابق جڑ رہی تھیں۔ ایک ہی اکاؤنٹ پر ایک گروہ ناکام اور دوسرا ٹھیک ہونا یہی تقسیم سب سے سستا سراغ ہے۔
بے ترتیبی کا دائرہ درست طور پر متعین کریں۔ یہ ہر کنکشن کوشش پر ہوتی ہے۔ قائم شدہ ٹنل اپنا اینڈ پوائنٹ دوبارہ حل نہیں کرتا، سیشن کے بیچ میں سرور نہیں بدلتا، اور انفرادی ایپلیکیشن درخواستیں ہر ایک نیا VPN ہوسٹ نہیں چنتیں۔ صرف اگلی کوشش دوبارہ حل کرتی ہے، اسی لیے ساری دوپہر چلنے والا سیشن کل صبح کے بارے میں کچھ نہیں کہتا۔
ٹنل اٹھتے وقت سروس کیا جانچتی ہے
Client VPN مطالبہ کرتا ہے کہ جس پتے سے آپ جڑے ہیں وہ اینڈ پوائنٹ کے DNS نام کے لیے حل شدہ پتے سے میل کھائے۔ یہی ایک شرط کئی بظاہر غیر متعلق ناکامیوں کی وضاحت کرتی ہے: کسی اور جگہ اشارہ کرنے والا حسب ضرورت DNS ریکارڈ، اصل اینڈ پوائنٹ پتے کی طرف بھیجنے والا حسب ضرورت فرنٹ اینڈ، اور خام پتے پر دوبارہ لکھی گئی پروفائل۔ AWS حسب ضرورت ریکارڈ اور فارورڈنگ کے امتزاج کو نئے AWS کلائنٹس کے ساتھ ناکامی کے طور پر درج کرتا ہے۔ جانچ تنگ ہے؛ یہ ہر عرفی نام کی ممانعت کا فیصلہ نہیں۔
یہ VPN پروٹوکول کے بارے میں عمومی اصول بھی نہیں ہے۔ عددی remote عام OpenVPN تعیناتی میں مکمل طور پر درست ہے، اور بہت سے اسی طرح چلتے ہیں۔ پابندی زیرِ انتظام ترتیب سے آتی ہے، اس کے نیچے کے پروٹوکول سے نہیں۔
جو سرٹیفکیٹ کی تصدیق ڈھیلی کرنے کو غلط ردعمل بناتا ہے۔ اگر پتہ بدلنے کے بعد پروفائل ناکام ہو تو سرور کی تصدیق بند کرنا حل یا پتہ میل کھانے کی شرط درست کرنے کے بجائے خرابی کو سرکاتا ہے، اور ایسا کلائنٹ چھوڑ دیتا ہے جو کسی بھی چیز پر بھروسہ کرے گا۔ برآمد شدہ CA، سرور کی تصدیق اور باہمی توثیق کی ترتیبات ویسی ہی رکھیں جیسی آئی تھیں۔
اجازت فہرستیں، اخراج اور نجی DNS تین الگ مسائل ہیں
لیپ ٹاپ کے جڑنے سے پہلے منزل کی اجازت دینے والا فائر وال اصول بیرونی سامع سے متعلق ہے۔ نیٹ ورک مالک کو اینڈ پوائنٹ نام، ٹرانسپورٹ اور ترتیب شدہ پورٹ دیں، پھر پوچھیں کہ کیا ان کا کنٹرول سروس کے DNS رویے کی پیروی کر سکتا ہے۔ ایک پکڑے گئے پتے کو رکھنے والا اصول بغیر لکھی مدت کی تصویر ہے۔ اگر کنٹرول صرف ناقابلِ تبدیل منزلیں قبول کرتا ہے تو رول آؤٹ سے پہلے وہ خلا پُر کریں، خاموشی سے جواب ہارڈ کوڈ کرنے کے بجائے۔
ٹنل کے اٹھنے کے بعد کی درخواستوں کے لیے مستقل ماخذ پتہ چاہنے والے پارٹنر کی الگ ضرورت ہے: اخراج۔ ویب سائٹ جو دیکھتی ہے وہ ایپلیکیشن روٹ اور اسپلٹ ٹنل پالیسی پر منحصر ہے، اس پتے پر نہیں جس سے کلائنٹ جڑا۔ اسپلٹ ٹنل ٹریفک AWS کو بالکل نہ چھوئے۔
ٹنل کے اندر نجی DNS تیسری تہہ ہے۔ کلائنٹ کو دیا گیا حل کنندہ جڑنے کے بعد اندرونی ناموں کا جواب دیتا ہے؛ ٹنل بننے سے پہلے وہ عوامی اینڈ پوائنٹ حل نہیں کر سکتا۔ اینڈ پوائنٹ حل کرنے کی ناکامی اور اندرونی ایپلیکیشن حل کرنے کی ناکامی مختلف مراحل میں ہوتی ہیں، اور انہیں ملانا آپ کو غلط لاگ پر بھیجتا ہے۔
پتہ خاندان بھی اسی فہرست میں ہے۔ IPv4 جواب IPv6 یا دوہرے اسٹیک اینڈ پوائنٹ کے مجاز راستے کے بارے میں کچھ نہیں کہتا، اس لیے ایک خاندان میں لی گئی تصویر دوسرے کے لیے ثبوت نہیں۔
کچھ بھی پن کیے بغیر رابطہ جانچیں
برآمد شدہ پروفائل سے ہی شروع کریں اور پڑھیں کہ وہ واقعی کیا مانگتی ہے:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'پھر تین چیزوں کا موازنہ کریں: پروفائل میں موجود اینڈ پوائنٹ نام، نئی کوشش کے لیے کلائنٹ کا بتایا گیا پتہ، اور نام اب کس چیز میں حل ہوتا ہے۔ حل ہونے والا نام صرف یہ ثابت کرتا ہے کہ ریکارڈ جواب دیتا ہے؛ ٹرانسپورٹ اور توثیق الگ ہیں، اور اینڈ پوائنٹ کو ping کا جواب دینا ضروری نہیں۔ درمیانی شے کے لیے کلائنٹ کا اپنا لاگ ہی واحد ماخذ ہے، اس لیے اسے کوشش کے دوران پکڑیں، بعد میں نہیں۔
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
آج جواب دینے والا پتہ آج کے بارے میں ثبوت ہے؛ نام ہی وہ چیز ہے جسے سروس درست رکھتی ہے۔ مشاہدہ درج کریں، اینڈ پوائنٹ کے مالک کو بھیجیں، اور پروفائل کو نام کی طرف اشارہ کرتا رہنے دیں۔
دو عادتیں چھوڑیں: رکے ہوئے ہینڈ شیک سے گزرنے کے لیے سرٹیفکیٹ جانچ بند کرنا، اور ایک چپک جائے گی کی امید میں اینڈ پوائنٹ نام کے آگے لیبل ڈھیر کرنا۔ لیبل وائلڈ کارڈ ریکارڈ کے ذریعے حل ہوتا ہے یا مسئلہ کہیں اور ہے۔ اگر درست ترتیب دی گئی پروفائل پھر بھی ناکام ہو تو لمبا ہوسٹ نام نہیں، درست کوئری اور کنکشن واقعہ بھیجیں۔
بند کرنے سے پہلے: پروفائل میں اب بھی برآمد شدہ اینڈ پوائنٹ نام ہے، کوئی hosts فائل پتہ پن نہیں کرتی، کلائنٹ لاگ کا remote موجودہ حل سے میل کھاتا ہے، اور فائر وال اصول پتے کے بجائے اینڈ پوائنٹ کا نام لیتا ہے۔ اگلے شخص کو سونپنے کی حالت بھی یہی ہے۔