دوہری اسٹیک VPN: ایڈریس فیملی کلائنٹ چنتا ہے، آپ نہیں

ٹنل چل رہا ہے، IPv4 سائٹیں لوڈ ہو رہی ہیں، اور ایک ہوسٹ نام کا وقت ختم ہو رہا ہے۔ فوری نتیجہ یہ نکلتا ہے کہ VPN خراب ہے یا اسناد غلط ہیں، اور عام طور پر دونوں میں سے کوئی سچ نہیں ہوتا۔ نام نے IPv4 اور IPv6 دونوں پتے واپس کیے، ایپ نے ایک چنا، اور ان امیدواروں میں سے صرف ایک کا کام کرنے والا راستہ تھا۔ انتخاب کا فیصلہ کلائنٹ نے کیا؛ ٹنل نے صرف وہ نہیں ڈھانپا جو اس نے چنا تھا۔

انتخاب کوریج کا وعدہ نہیں ہے

RFC 6724 میں بیان کردہ ڈیفالٹ ایڈریس انتخاب طے کرتا ہے کہ جب کئی دستیاب ہوں تو ہوسٹ کس ماخذ اور منزل کے جوڑے کو ترجیح دے گا۔ Happy Eyeballs اس پر کنکشن حکمت عملی شامل کرتا ہے: دونوں فیملیوں میں کوششیں شروع کرتا ہے اور جو پہلے جواب دے اسے رکھتا ہے، تاکہ صارف کو خراب فیملی کے ٹائم آؤٹ کا انتظار نہ کرنا پڑے۔

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

اسی پیچھے ہٹنے کی وجہ سے علامت ایپس کے درمیان غیر مسلسل ہے۔ براؤزر تاخیر چھپاتا ہے؛ مقررہ فیملی والا کمانڈ لائن کلائنٹ اصل ناکامی فوراً دکھاتا ہے۔

معلوم کریں کہ درخواست نے واقعی کون سی فیملی استعمال کی

ٹنل سے نہیں، نام سے شروع کریں۔ دونوں ریکارڈ اقسام پوچھیں اور لکھیں کہ کیا واپس آیا:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

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

فیملی اور منزل اپنے نوٹس میں رکھیں۔ وہ ٹکٹ جو کہے کہ سائٹ VPN پر لوڈ نہیں ہوتی، اسے کوئی جانچ نہیں سکتا، جبکہ وہ ٹکٹ جو کہے کہ AAAA ناکام ہوتا ہے اور A کام کرتا ہے، کسی مخصوص راستے کی طرف اشارہ کرتا ہے۔

اس فیملی کے لیے راستہ جانچیں

ناکام ہونے والی فیملی کے لیے کرنل سے پوچھیں کہ کون سا راستہ استعمال کرے گا اور اسے ٹنل کے ترتیب شدہ پتوں سے موازنہ کریں۔ Linux پر، ip -6 route get منزل کے لیے منتخب ہونے والا انٹرفیس اور ماخذ دکھاتا ہے۔

پھر ٹنل کو خود جانچیں۔ WireGuard ساتھی اجازت یافتہ IP کی فہرست رکھتے ہیں، اور 0.0.0.0/0 کے لیے اندراج IPv6 کے بارے میں کچھ نہیں کہتا۔ اگر ساتھی کی فہرست میں IPv6 سابقہ نہیں ہے، تو کلائنٹ کے پاس AAAA ٹریفک ٹنل میں بھیجنے کی کوئی وجہ نہیں، اور پیکٹ اسی راستے سے نکلتا ہے جو ہوسٹ بصورت دیگر اختیار کرتا۔

فائر وال قواعد اور NAT پالیسی ہر فیملی کے لیے اسی جانچ کی مستحق ہیں۔ IPv4 کے لیے لکھا گیا قاعدہ کسی بھی پلیٹ فارم پر IPv6 کو نہیں ڈھانپتا، اور یہی سب سے عام وجہ ہے کہ ایک فیملی کام کرتی ہے اور دوسری نہیں۔

اسکرین شاٹ آسان بنانے کے لیے IPv6 بند نہ کریں

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

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

ٹکٹ میں کیا لکھیں

چار چیزیں درج کریں: ہوسٹ نام، ناکام ہونے والی فیملی، کرنل کا چنا ہوا راستہ، اور فیملی کے لیے مخصوص درخواست کا نتیجہ۔ یہ مجموعہ کسی اور کے لیے ناکامی دہرانے کے لیے کافی ہے، بغیر یہ اندازہ لگائے کہ آپ کی مراد دو راستوں میں سے کون سا تھا۔

RFC 6724 ایڈریس انتخاب کے قواعد وضاحت کرتے ہیں کہ کلائنٹ نے اس امیدوار کو کیوں ترجیح دی، اور RFC 8305 اس دوڑ کے رویے کی وضاحت کرتا ہے جس نے تاخیر چھپائی۔ ان میں سے کوئی آپ کے لیے پیکٹ روٹ نہیں کرے گا، اور ٹنل کو یہی حصہ کرنا ہے۔