اینڈرائیڈ، iOS اور ونڈوز پر پنگ کے بغیر VPN کی حالت کیسے جانچیں

192.0.2.10 کو ping کرنے سے آپ کو صرف یہ پتہ چلتا ہے کہ ایک پتہ نے ICMP ایکو کا جواب دیا، بس اتنا ہی۔ بغیر ٹنل والے نیٹ ورک پر یہ پھر بھی کامیاب ہو سکتا ہے، کیونکہ پتہ مقامی سب نیٹ پر ہو سکتا ہے؛ صحت مند ٹنل کے ساتھ یہ ناکام بھی ہو سکتا ہے، کیونکہ سرور HTTPS پیش کرتے وقت ICMP چھوڑ دیتا ہے۔ آپ کی اسکرپٹ کو جس جانچ کی ضرورت ہے وہ پلیٹ فارم کی حالت کی استفسار اور ایپ کے استعمال کردہ منزل تک راستے کی جانچ ہے۔ انہیں دو الگ فیلڈ سمجھیں، کبھی ایک بولین کے طور پر نہیں۔

ایکو جواب واقعی کیا ثابت کرتا ہے

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

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

رسائی اور ٹنل کی حالت الگ الگ حقائق ہیں، اور ایک سچ ہو سکتا ہے جبکہ دوسرا جھوٹا۔ انہیں الگ رکھنے سے پتہ چلتا ہے کہ خرابی کس کی ہے۔ انہیں ایک ہی جانچ میں ملا دینے سے ایسا ٹکٹ بنتا ہے جسے کوئی روٹ نہیں کر سکتا۔

Android سے پنگ نہیں، ٹرانسپورٹ پوچھیں

Android حالت کے سوال کا جواب ConnectivityManager کے ذریعے براہ راست دیتا ہے۔ فعال نیٹ ورک کی صلاحیتوں میں VPN ٹرانسپورٹ کا جھنڈا ہوتا ہے، جو اس وقت سیٹ ہوتا ہے جب ٹریفک VPN انٹرفیس سے روٹ ہو۔ یہ کال مقامی، سستی اور اس بات سے آزاد ہے کہ کوئی دور دراز ہوسٹ جواب دیتا ہے یا نہیں۔

Java کا یہ ورژن فعال نیٹ ورک نہ ہونے پر استثنا پھینکنے کے بجائے false واپس کرتا ہے۔ چونکہ یہ فعال نیٹ ورک پڑھتا ہے، یہ وہی پروفائل ظاہر کرتا ہے جو صارف نے سیٹنگز میں منتخب کیا۔

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

تبدیلی کی اطلاعات کے لیے ٹائمر پر پولنگ کے بجائے NetworkCallback رجسٹر کریں۔ اسے VpnService.prepare سے نہ ملائیں، جو صرف یہ بتاتا ہے کہ صارف نے VPN کے لیے اجازت دی یا نہیں، یہ نہیں کہ پیکٹ بہہ رہے ہیں۔ منسوخی VpnService.onRevoke سے آتی ہے، تاہم سیٹنگز میں پروفائل بھول جانے سے کوئی نشریات نہیں ہوتیں۔

iOS: انٹرفیس کے نام ایک اندازہ ہیں، معاہدہ نہیں

بہت سے iOS ٹکڑے پراکسی سیٹنگز کی جانچ کرتے ہیں، __SCOPED__ ڈکشنری تلاش کرتے ہیں اور tap, tun, utun2, ppp یا ipsec جیسی انٹرفیس کلیدیں ڈھونڈتے ہیں۔ یہ طریقہ نام رکھنے کی روایت ہے، دستاویزی ضمانت نہیں، اس لیے انٹرفیس کا نام بدلنے والا OS اپ ڈیٹ اسے توڑ سکتا ہے۔ یہ ٹنل سے زیادہ جینے والے پرانے اندراجات کے لیے true بتانے کا رجحان بھی رکھتا ہے۔

جب ترتیب آپ کی ایپ کے پاس ہو، تو اس کے بجائے NEVPNManager حقیقی حالت دیتا ہے۔ یہ وہ ٹنل بیان کرتا ہے جو آپ کی ایپ نے شروع کیا؛ فی ایپ VPN کے ساتھ، دوسری ایپس اس ٹنل سے مکمل باہر ہو سکتی ہیں۔

حالت پڑھنے سے پہلے ترجیحات دوبارہ لوڈ کریں، کیونکہ ٹنل کے چڑھنے اور اترنے پر قدر بدلتی ہے:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

پلیٹ فارم کا حالت کا جھنڈا پھر بھی یہ ثابت نہیں کرتا کہ ٹریفک ساتھی تک پہنچتی ہے۔ یہی خلا راستے کی جانچ پر کرتی ہے، اور اسی لیے معاونت کے لیے ایک بولین کافی نہیں۔

Windows پروفائل حقیقی حالت کا فیلڈ دکھاتے ہیں

Windows VPN پروفائل کو اڈاپٹرز سے الگ ٹریک کرتا ہے، اور Get-VpnConnection ہر معلوم پروفائل کے لیے ConnectionStatus دکھاتا ہے۔ Windows کلائنٹ یا پروویژننگ پیکیج سے بنائے گئے پروفائل یہاں ظاہر ہوتے ہیں۔ یہ cmdlet عمومی ٹنل ڈیٹیکٹر نہیں ہے۔

نامزد پروفائل کے لیے فیلڈ پڑھیں، اور جب پروفائل تمام صارفین کا ہو تو -AllUserConnection شامل کریں:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

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

حالت اور راستہ: دو حصوں کی جانچ

منسلک پروفائل اس بارے میں کچھ نہیں کہتا کہ پیکٹ کہاں جاتے ہیں۔ تقسیم شدہ ٹنلنگ ٹنل کو فعال رکھتے ہوئے اس منزل کو خارج کر سکتی ہے جس کی آپ کو پرواہ ہے۔ always-on پروفائل مردہ سرور کے ساتھ بھی منسلک رہتے ہیں، اور ٹنل گرنے پر kill switch جان بوجھ کر ٹریفک روکتا ہے۔

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

ip route get 192.0.2.10
resolvectl query intranet.example.test

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

ایک جانچ جو آپ ترتیب سے چلا سکتے ہیں

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

dig اور curl والی Linux مشین پر، تین کمانڈز حل، راستہ اور خود سروس کا احاطہ کرتی ہیں۔ انہیں ٹنل چڑھنے پر چلائیں اور پھر اترنے پر دوبارہ:

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

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