نجی DNS VPC میں کام کرتا ہے مگر VPN پر نہیں
ایک نجی نام جو EC2 کے اندر حل ہوتا ہے مگر VPN پر نہیں، resolver کے راستے کا مسئلہ ہے۔ زون ریکارڈ تبدیل کرنے سے پہلے ناکامی کی شکل پڑھیں۔
ایک نجی نام EC2 انسٹینس سے حل ہوتا ہے مگر VPN سے منسلک لیپ ٹاپ سے نہیں، اور زون کنسول میں درست دکھائی دیتا ہے۔ پہلا ردِعمل ریکارڈ میں ترمیم کرنا ہوتا ہے، جو تقریباً کبھی مسئلہ نہیں ہوتا۔ ریکارڈ کسی کو جواب دے رہا ہے؛ صرف آپ کے لیپ ٹاپ کو جواب نہیں دے رہا۔ دونوں طلب کرنے والوں میں فرق یہ ہے کہ وہ کون سا resolver پوچھتے ہیں اور کیا اُس resolver کا VPC کے DNS منظر تک معاون راستہ ہے۔
میں یہ ثابت کر کے شروع کرتا ہوں کہ ریکارڈ موجود ہے، پھر باقی وقت استفسار کے راستے پر صرف کرتا ہوں۔ یہ الگ نظام ہیں اور مختلف طریقوں سے ناکام ہوتے ہیں۔
کچھ بھی بدلنے سے پہلے ناکامی کی شکل پڑھیں
تین نتائج تین مختلف چیزیں مانتے ہیں، اور ایک استفسار اُن میں فرق کرتا ہے: اُس resolver کے خلاف نام کے لیے dig چلائیں جو کلائنٹ واقعی استعمال کر رہا ہے۔
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
وقت کا خاتمہ نیٹ ورک کے بارے میں ایک بیان ہے۔ NXDOMAIN، DNS منظر کے بارے میں ایک بیان ہے۔ عوامی جواب پالیسی کے بارے میں ایک بیان ہے۔ وقت کے خاتمے کے دوران زون ریکارڈ میں ترمیم کرنا کیس کا واحد کارآمد ثبوت پھینک دیتا ہے۔
کیوں VPC کا جمع دو پتہ دور کا resolver نہیں ہے
CIDR جمع دو پتہ VPC کے اندر موجود وسائل کے لیے مقامی خدمت ہے۔ AWS دستاویز کرتا ہے کہ مقامی نیٹ ورکس سے، یا کسی دوسرے VPC کے DNS سرورز سے، استفسارات کو براہِ راست اُس پتے پر بھیجنا معاون نہیں اور غیر مستحکم نتائج دے سکتا ہے۔
اس کا مطلب یہ نہیں کہ تجربہ کبھی کام کرتا دکھائی نہیں دیتا۔ اس کا مطلب یہ ہے کہ رویہ کوئی معاہدہ نہیں جسے آپ ہیلپ ڈیسک اسکرپٹ میں رکھ سکیں۔ معاون سمت ایک آنے والا Resolver endpoint ہے: آپ کے VPC کے اندر پتوں کا ایک جوڑا، جو آپ کے زیرِ کنٹرول نیٹ ورک سے قابلِ رسائی ہو اور AWS سے باہر سے آنے والے استفسارات قبول کرے۔
راستہ اُس ترتیب سے بنائیں جس میں وہ صاف ناکام ہوتا ہے
تین چھلانگیں ہونی چاہئیں اور ہر ایک کی ناکامی کا اپنا طریقہ ہے۔
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesفارورڈر کو VPN کے ذریعے endpoint کے پتوں تک راستہ درکار ہے، اور واپسی کا راستہ بھی کام کرنا چاہیے۔ پورٹ 53 پر روایتی DNS کے لیے endpoint UDP اور TCP پر جواب دیتا ہے، لہٰذا دونوں پروٹوکول کی اجازت ہونی چاہیے اور دونوں کو درمیان میں کسی بھی حالتی جانچ سے گزرنا ہوگا۔
پھر DNS منظر کو الگ سے جانچیں۔ نجی میزبان زون صرف اُن VPCs کو نظر آتا ہے جن سے وہ منسلک ہے، یا کسی دانستہ اشتراک کے انتظام کے ذریعے۔ قابلِ رسائی endpoint بذاتِ خود ہر نجی زون کو اپنے حل کے سیاق میں حل پذیر نہیں بناتا۔
باہر جانے والا endpoint مخالف سمت کی خدمت کرتا ہے اور آپ کے لیپ ٹاپ سے آنے والے استفسار کا جواب نہیں دے گا۔
دونوں سروں سے تصدیق کریں
کلائنٹ سے فارورڈر کی طرف، پھر فارورڈر سے endpoint کی طرف استفسار کریں۔ اگر کلائنٹ ناکام ہو جبکہ فارورڈر کامیاب ہو، تو خلا اُن دونوں کے درمیان ہے۔
اگر دونوں ناکام ہوں تو endpoint پر سلامتی کی پالیسی اور اُس ماخذ پتے کو دیکھیں جو وہ واقعی دیکھتا ہے۔ NAT کے پیچھے فارورڈر لیپ ٹاپ کے VPN پتے کی بجائے NAT پتہ پیش کرتا ہے، اور صرف یہی فرق استفسار گرا دینے کے لیے کافی ہے۔ اگر دونوں کامیاب ہوں مگر ایپلیکیشن پھر بھی ناکام ہو، تو ممکن ہے ایپلیکیشن اُس سے مختلف resolver استعمال کر رہی ہو جو آپ نے آزمایا۔
عوامی اور نجی نام کی جگہوں کو دانستہ الگ رکھیں۔ Split DNS ایک پالیسی ہے جو آپ ترتیب دیتے ہیں، نہ کہ ایک تلاش کے اتفاقاً ڈیٹا واپس کرنے کا ضمنی اثر۔
جو میں نہ کرتا
میں ایسا NAT قاعدہ شامل نہ کرتا جس نے ایک تلاش چلا دی اور اُسے ڈیزائن کہہ دوں۔
میں ہر دور کے کلائنٹ کو جمع دو پتے کی طرف نہ موڑتا صرف اس لیے کہ ایک آزمائش نے ایک بار ریکارڈ واپس کیا۔ اور میں endpoint کی سلامتی کی پالیسی کو پورے VPN پول تک نہ پھیلاتا جب ایک ہی فارورڈر کو رسائی درکار ہو۔ اگر تنظیم پہلے سے VPC کے اندر منظور شدہ فارورڈر چلا رہی ہے تو پہلے وہ ڈیزائن پڑھیں، کیونکہ آپ کا شامل کردہ دوسرا endpoint وہی ہے جسے کوئی دستاویز نہیں کرتا۔