آپ کا split tunnel قاعدہ کسی سروس سے میل کھانا کیوں بند ہو گیا

split tunneling عام طور پر دو طریقوں میں سے ایک سے ناکام ہوتا ہے۔ یا تو وہ ٹریفک جو ٹنل کے اندر ہونا چاہیے اسے گھوم کر نکل جاتا ہے، یا وہ ٹریفک جو باہر رہنا چاہیے اندر کھینچ لیا جاتا ہے۔ پرانے قاعدے کی ناکامی پہلی قسم ہے، اور یہ زیادہ الجھن پیدا کرتی ہے، کیونکہ قاعدہ بالکل ویسے ہی نافذ ہوتا ہے جیسے لکھا گیا ہے۔ جو بدلا وہ منزل ہے: سروس اب ایسے پتے پر جواب دیتی ہے جس کا نام قاعدے نے کبھی نہیں لیا، اور ٹنل میں کچھ بھی غلط نہیں ہے۔

قاعدہ کیا مقرر کرتا ہے اور DNS کیا واپس دیتا ہے

split tunnel قاعدہ منزلوں کے بارے میں ایک مستقل بیان ہے، جو عام طور پر سابقہ، راستہ یا پتوں کی فہرست کے طور پر بیان ہوتا ہے۔ بھیجنے کے وقت اس کا اندازہ پیکٹ کی منزل کے مقابلے میں ہوتا ہے۔ میزبان نام ایک تلاش ہے جو عمر اور کیش کے ساتھ پتوں کا مجموعہ واپس دیتی ہے، اور جواب resolver، سوال کی قسم اور منٹ کے لحاظ سے مختلف ہو سکتا ہے۔

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

میل کھانے کے ٹوٹنے کے تین طریقے

واضح معاملہ منتقل شدہ سروس ہے: آپریٹر نے اسے نیا پتہ دیا، DNS نے پیچھا کیا، اور استثنا نے نہیں۔ دوسرا پتوں کا خاندان ہے جسے قاعدے نے کبھی نہیں ڈھانپا، یہ تب ہوتا ہے جب کوئی نام ایسے AAAA ریکارڈ واپس کرنا شروع کرے جنہیں صرف IPv4 کے لیے استثنا نظر انداز کرتا ہے۔ تیسرا resolver کا فرق ہے: اندرونی اور عوامی منظر ایک ہی نام کے لیے مختلف پتے واپس کر سکتے ہیں، اس لیے آپ کی ایپ جو پتہ استعمال کرتی ہے وہ نہیں جس سے آپ نے جانچ کی۔

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

وہ منزل پڑھیں جو ایپ واقعی استعمال کرتی ہے

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

علامت نہیں، میکانزم درست کریں

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

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

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

ارادے کے دونوں حصوں کی تصدیق کریں

split tunnel ڈیزائن کے دو ارادے ہیں، اور مرمت کو دونوں محفوظ رکھنے چاہئیں۔ محفوظ سروس کو ٹنل سے گزرنا چاہیے، اور خارج شدہ زمرے اسے گھومتے رہنا چاہیے۔ مرمت شدہ منزل سے نیا کنکشن جانچیں، پھر کوئی ایسی چیز جانچیں جو باہر رہنی چاہیے۔

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

نیا پتہ، منتخب میکانزم اور تاریخ لکھیں۔ یہی نوٹ اگلے شخص کو یہ نتیجہ اخذ کرنے سے روکتا ہے کہ VPN نے اپنی ہی ترتیب کو بے ترتیب طور پر نظر انداز کیا۔