ddclient VPN کا اخراج شائع کرتا ہے: دریافت کا ماخذ درست کریں

آپ کا DNS نام اب کسی VPN فراہم کنندہ کے پتے پر حل ہوتا ہے، اور اپ ڈیٹ لاگ بالکل صحت مند دکھائی دیتا ہے۔ یہ امتزاج معمول ہے۔ ویب پر مبنی دریافت پروب کسی بیرونی سروس سے پوچھتا ہے کہ اسے کون سا ماخذ نظر آتا ہے، اور جب درخواست مکمل ٹنل VPN سے باہر جاتی ہے تو جواب VPN کا اخراج ہوتا ہے، آپ کا گھریلو WAN پتہ نہیں۔ اپ ڈیٹر نے اپنا کام کیا؛ کام غلط مشاہدے کی طرف مبذول تھا۔

تصدیق کریں کہ نام کو کہاں پہنچنا چاہیے

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

VPN کلائنٹ کے ٹنل پتے کے لیے نجی نام ایک الگ مسئلہ ہے جس کا الگ جواب ہے: یہ نجی DNS میں آتا ہے، اور اسے عوامی دریافت سروس کی سرے سے ضرورت نہیں۔ دونوں تقاضوں کو ملانا ہی وہ طریقہ ہے جس سے کام کرتی ترتیب ایسا پتہ شائع کرنے لگتی ہے جو کسی نے نہیں مانگا۔

انٹرفیس پتوں کی بھی تشریح درکار ہے۔ گھریلو راؤٹر کے پیچھے لیپ ٹاپ کا پتہ عوامی WAN پتہ نہیں ہے، اور خود راؤٹر کا WAN پتہ بھی کیریئر گریڈ NAT کے پیچھے ہو سکتا ہے، جہاں اسے شائع کرنے سے آنے والی رسائی پیدا نہیں ہو سکتی۔

کچھ بھی بدلنے سے پہلے قدر دوبارہ پیدا کریں

دونوں راستوں کو الگ الگ دیکھیں۔ ٹنل فعال ہونے پر پروب اخراج بتاتا ہے؛ ٹنل بند ہونے پر، یا پروب کے جسمانی انٹرفیس سے بندھے ہونے پر، یہ گھر کا پتہ بتاتا ہے: curl --interface eth0 https://ifconfig.me. اگر وہ دو جواب مختلف ہیں تو آپ نے اپ ڈیٹر کو چھوئے بغیر خرابی دوبارہ پیدا کر لی ہے۔

پھر کلائنٹ کو ایسے موڈ میں چلائیں جو اپ ڈیٹ کیے بغیر ترتیب جانچے، مثلاً ddclient -verbose -noexec، اور پڑھیں کہ اس نے دریافت کا کون سا طریقہ چنا۔ تفصیلی آؤٹ پٹ طریقہ اور حاصل شدہ قدر بتاتا ہے، اور کچھ بھی ترمیم کرنے سے پہلے آپ کو یہی حقیقت درکار ہے۔

دریافت کو منتخب راستے کی طرف مبذول کریں

اگر نام کو گھریلو WAN پتہ شائع کرنا ہے تو دریافت کو وہی پتہ دیکھنا ہوگا۔ تقریباً ترجیحی ترتیب میں تین اختیارات کام کرتے ہیں: راؤٹر کو اپنے معاون اپ ڈیٹر کے ذریعے شائع کرنے دیں؛ راؤٹر واقعی جو صفحہ پیش کرتا ہے اس کے خلاف ddclient کی راؤٹر-حالت دریافت استعمال کریں؛ یا ویب پروب رکھیں مگر اسے جسمانی انٹرفیس سے باندھیں تاکہ یہ ٹنل سے باہر نکلے۔

راؤٹر-حالت راستے کے لیے، نئے ddclient ورژن usev4 اور fwv4 اختیار خاندان استعمال کرتے ہیں، صفحے کے ارد گرد متن کے لیے اختیاری چھوڑنے کا نمونہ بھی۔ اپنے نصب شدہ ورژن کا README دیکھیں، کیوں کہ پرانے ورژن وہی خیال use اور fw سے لکھتے ہیں، اور غلط ورژن سے نقل کیا گیا اختیار نام شروع ہوتے وقت ناکام ہوتا ہے۔

اگر آپ ویب دریافت رکھتے ہیں تو یاد رکھیں کہ پروب کی روٹنگ اور اپ ڈیٹ API کال کی روٹنگ الگ فیصلے ہیں۔ اپ ڈیٹ کال ریکارڈ پہنچاتی ہے؛ پروب طے کرتا ہے کہ کون سی قدر پہنچائی جائے گی۔

راز اور ورژن سلیقے سے رکھیں

راؤٹر کی اسناد اور فراہم کنندہ کے ٹوکن محفوظ ترتیب فائل میں ہونے چاہئیں، shell تاریخ میں پہنچنے والی کمانڈ لائن پر نہیں۔ تفصیلی نشانات دونوں رکھ سکتے ہیں، اس لیے ٹکٹ میں چپکانے سے پہلے انھیں مٹا دیں۔ جس دریافت طریقے کے لیے تصدیق شدہ راؤٹر صفحہ کھرچنا پڑے، اس کے لیے فرم ویئر اپ ڈیٹس کے دوران بھی وہ اسناد کام کرتی رہنی چاہئیں۔ انھیں فراہم کنندہ کے ٹوکن جیسی احتیاط سے محفوظ رکھیں۔

ddclient README دریافت کے طریقوں اور ان کے اختیار ناموں کی دستاویز کرتا ہے۔ ایک ہی ریکارڈ میں IPv4 اور IPv6 نتائج نہ ملائیں، اور یہ فرض نہ کریں کہ ایک ورژن میں موجود اختیار دوسرے میں بھی ہے۔

قدر کی تصدیق کریں، پھر رسائی کی

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

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