AWS Client VPN میں DNS: subnet نہیں، VPC resolver استعمال کریں

endpoint 10.0.8.0/24 میں ہے، اس لیے resolver 10.0.8.2 ہونا چاہیے۔ یہی سب سے زیادہ سنی جانے والی دلیل ہے اور یہ دو بار غلط ہے۔ Route 53 Resolver بنیادی VPC IPv4 رینج جمع دو پر جواب دیتا ہے، جو 10.0.0.0/16 کے VPC کے لیے 10.0.0.2 ہے، endpoint کوئی بھی subnet استعمال کرے۔ دوسری غلطی زیادہ خاموش ہے: endpoint میں درست پتہ رکھنے کا مطلب یہ نہیں کہ client کا آپریٹنگ سسٹم کبھی اس سے کچھ پوچھے۔ دونوں غلطیاں ایک ہی علامت دیتی ہیں: ناموں کا حل کچھ client پر چلتا ہے اور کچھ پر ناکام ہوتا ہے۔

افسانہ subnet کے تعلق سے شروع ہوتا ہے

تعلق اس بارے میں ہے کہ client کنکشن کے لیے elastic network interfaces کہاں رہتے ہیں، اس بارے میں نہیں کہ کون سا resolver پتہ موجود ہے۔ endpoint کے subnet client کو VPC کے اندر پتہ دیتے ہیں، اور ان میں سے ہر ایک اپنا resolver نہیں رکھتا۔

جیسے ہی آپ ان دو خیالوں کو الگ کرتے ہیں، حساب پراسرار رہنا چھوڑ دیتا ہے اور مسئلے کا حل client کی طرف چلا جاتا ہے، جہاں ان میں سے بیشتر معاملات واقعی ختم ہوتے ہیں۔

بنیادی VPC رینج سے پتہ شمار کریں

VPC کا بنیادی IPv4 CIDR لیں اور نیٹ ورک پتے میں دو جمع کریں۔ 10.0.0.0/16 10.0.0.2 دیتا ہے، 172.31.0.0/16 172.31.0.2 دیتا ہے، اور ثانوی رینج والا VPC resolver کو بنیادی پر ہی رکھتا ہے۔ اس VPC کے اندر 10.0.8.0/24 کا subnet اسے ہلاتا نہیں۔ endpoint کو چھونے سے پہلے پتہ VPC ID کے ساتھ لکھیں، کیونکہ یہ عدد VPC کی خاصیت ہے، کنکشن کی نہیں۔

VPC link-local پتے 169.254.169.253 پر بھی جواب دیتا ہے۔ یہ پتہ VPC کے اندر سے قابل رسائی ہے، لیکن سرنگ کے دوسرے سرے پر رکھے لیپ ٹاپ کے لیے یہ عام روٹ شدہ منزل نہیں ہے۔

تو دو درست resolver پتے ہیں، اور ان میں سے کوئی بھی subnet جمع دو نہیں ہے۔

endpoint کی سیٹنگ کیا کرتی ہے اور کیا نہیں

Client VPN endpoint میں DNS سرور کے خانے ہیں، اور جہاں console VPC resolver کا اختیار دیتا ہے وہاں وہی خیال بھر دیتا ہے۔ انہیں سیٹ کرنے سے بدلتا ہے کہ کنکشن قائم ہوتے وقت سروس client کو کیا دیتی ہے۔ یہ نہیں بدلتا کہ غیر مدیریت شدہ OpenVPN client اس قدر کے ساتھ کیا کرتا ہے، کیونکہ client کو اسے آپریٹنگ سسٹم پر لاگو کرنا ہوتا ہے۔ «میرے Mac پر چلتا ہے مگر Linux بکس پر نہیں» اسی خلا سے آتا ہے۔

Linux میں resolver کا انضمام کنکشن مینیجر کی ملکیت ہے، صارف کی نہیں۔ /etc/resolv.conf کو ہاتھ سے تبدیل کرنا ثابت کرتا ہے کہ پتہ ایک سیشن کے لیے چلتا ہے اور پھر دوبارہ جڑنے پر غائب ہو جاتا ہے — اسی لیے بہت سے درست کیے گئے معاملات اگلی صبح واپس آ جاتے ہیں۔

جڑنے کے بعد client پر فعال resolver دیکھیں، endpoint کا کنفیگریشن صفحہ نہیں۔

split tunneling صحیح resolver کو ہرا سکتا ہے

split tunneling میں صرف وہ راستے استعمال ہوتے ہیں جو سرنگ میں دھکیلے جاتے ہیں۔ اگر resolver کا پتہ کسی راستے سے ڈھکا نہ ہو، تو استفسار مقامی انٹرفیس سے باہر جاتا ہے اور آپ کا گھریلو روٹر جواب دیتا ہے۔ endpoint کا پتہ اب بھی درست ہے اور تلاش اب بھی ناکام ہوتی ہے۔ resolver کے لیے راستہ شامل کریں، پھر دوبارہ جانچیں۔

ایک دوسرے پر چڑھنے والی مقامی رینجیں وہی نتیجہ زیادہ ناخوشگوار طریقے سے دیتی ہیں: استفسار کا جواب آتا ہے، مگر غلط سرور سے۔

Amazon DNS پتے کے لیے security groups نہ کھولیں

تلاشیں وقت سے گزر جائیں تو فطری رجحان resolver پتے پر UDP 53 کی اجازت دینے والا قاعدہ شامل کرنا ہے۔ AWS درج کرتا ہے کہ security groups اور network ACL Amazon DNS ٹریفک کو اس طرح فلٹر نہیں کرتے جیسے اپنے DNS انسٹانس کی طرف ٹریفک فلٹر کرتے ہیں۔ ان قواعد کو کھولنا VPC resolver کے لیے کچھ نہیں بدلتا اور بلا وجہ حد کو وسیع کرتا ہے۔ جو resolver آپ خود چلاتے ہیں وہ الگ معاملہ ہے اور اسے واقعی اپنے قواعد درکار ہیں۔

اگر آپ کے ڈیزائن میں دونوں ہیں، تو کوئی بھی قاعدہ تبدیل کرنے سے پہلے دیکھیں کہ client واقعی کس کی طرف اشارہ کر رہا ہے۔

راہ کی تصدیق کریں، پھر کوئی اور چیز ناپیں

کوئی عوامی نام حل کریں، VPC سے منسلک نجی ہوسٹڈ زون میں درج نجی نام حل کریں، اور دونوں کے درمیان client کا فعال resolver پڑھیں۔ یہ ترتیب «resolver پتہ غلط ہے» کو «زون منسلک نہیں» اور «client نے سیٹنگ نظرانداز کی» سے الگ کرتی ہے۔ ہر ایک کا الگ حل ہے، اور کوئی بھی throughput مسئلہ نہیں ہے۔

کامیاب تلاش مستقل منتقلی رفتار کے بارے میں کچھ نہیں کہتی، اس لیے رپورٹ کرتے وقت ان دو باتوں کو الگ رکھیں۔