Mac پر VPN کا utun انٹرفیس فعال ہے مگر ٹریفک ناکام؟ ifconfig دیکھیں

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

utun لائن میں واقعی کیا ہوتا ہے

جب پوری تصویر چاہیے ہو تو ifconfig -a چلائیں۔ بغیر دلیل بلائے جانے پر، ifconfig صرف وہی انٹرفیس چھاپتا ہے جو ابھی فعال ہیں، اسی لیے وہ سرنگ جو شروع نہ ہو سکی اُس آؤٹ پٹ سے غائب ہو سکتی ہے جو لوگ ٹکٹوں میں چپکاتے ہیں۔ ifconfig -l صرف نام واپس کرتا ہے، اور یہ جاننے کا تیز ترین طریقہ یہی ہے کہ جوڑنے کے بعد نیا utun آیا یا نہیں۔

ایک انٹرفیس پڑھنا ہی وہ جگہ ہے جہاں کارآمد تفصیل رہتی ہے، اور جڑی ہوئی سرنگ عام طور پر ایسی دکھتی ہے۔

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

تین خانے جواب اٹھاتے ہیں۔ UP اور RUNNING کہتے ہیں کہ کرنل انٹرفیس استعمال کرنے کو تیار ہے۔ POINTOPOINT کے ساتھ --> ساتھی کا پتہ جسمانی ربط نہیں بلکہ سرنگ کا دستخط ہے۔ mtu قدر "جڑتا ہے، پھر رک جاتا ہے" والی رپورٹوں کی پوری قسم کی وضاحت کرتی ہے، کیونکہ utun انٹرفیس عام طور پر کم کیے گئے MTU کے ساتھ اٹھتے ہیں، کئی macOS بلڈز میں 1380، اور کلائنٹ اسے بدل سکتا ہے۔ خانوں کی فہرست اتنی مختصر ہے کہ ایک بار دیکھ لی جائے Apple کے ساتھ دیے گئے ifconfig دستی میں۔

انٹرفیس کے پیچھے موجود عمل تلاش کریں

ifconfig کو مالک ایپ کا تصور نہیں۔ دو VPN کلائنٹ، ایک سسٹم سروس اور پچھلے ہفتے کی بچی ہوئی سرنگ، سب اس سطح پر ایک جیسے دکھنے والے اندراج بناتے ہیں۔ میرے اپنے Mac پر بھی، utun0 سے utun3 تک کچھ بھی ترتیب دینے سے پہلے موجود تھے؛ Continuity اور iCloud Private Relay بھی سرنگیں استعمال کرتے ہیں، اور ان میں سے کوئی بھی وہ کنکشن نہیں جو آپ جانچ رہے ہیں۔

اُن سرنگوں کے لیے جو نظام میں ترتیب درج کرتی ہیں، scutil --nc list تیز ترین ربط ہے، یہ ہر ترتیب کو اُس کی حالت اور سروس ID کے ساتھ چھاپتی ہے، اور جڑی ہوئی اسی طرح نشان زد ہوتی ہے۔

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

وہ کلائنٹ جو ترتیب درج کرنے کے بجائے اپنا سرنگ عمل چلاتے ہیں وہاں کبھی نظر نہیں آتے۔ Tunnelblick اور کمانڈ لائن کا openvpn نمونہ اسی گروہ میں آتا ہے، اس لیے عمل کا جدول بھی دیکھیں: ps -Ao pid,comm | grep -i openvpn۔ جب کوئی عمل سرنگ کا مالک ہو جائے تو utun نمبر صرف اسی عمل کا ہوتا ہے اور کسی اور کا نہیں۔

راستہ جانچنے سے پہلے پتہ جانچیں

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

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

ping -D -s 1372 10.8.0.5

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

ثابت کریں کہ منزل سرنگ چنتی ہے

اہم سوال utun4 موجود ہے یا نہیں یہ نہیں، بلکہ یہ ہے کہ ایک مخصوص پتے کی طرف ٹریفک اسی سے باہر جاتی ہے یا نہیں۔ route -n get ایک منزل کے لیے اس کا جواب دیتا ہے اور وہ گیٹ وے اور انٹرفیس چھاپتا ہے جو استعمال کرے گا:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

اگر وہی کمانڈ en0 بتائے، تو آپ کی split tunneling ترتیب وہی کر رہی ہے جو اُسے کہا گیا، اور انٹرفیس کی کتنی بھی جانچ اسے نہیں بدلے گی۔ netstat -rn -f inet استعمال کریں جب آپ کو ڈیفالٹ راستہ اور پوری جدول ایک نظر میں چاہیے ہو۔

پیکٹ واقعی حرکت کرتے ہیں یا نہیں، یہ کاؤنٹر طے کرتے ہیں۔ netstat -ib utun اندراجوں سمیت ہر انٹرفیس کے پیکٹ اور بائٹ کے مجموعے بتاتا ہے؛ اعداد جمعی ہیں، اس لیے وقفے سے دو بار پڑھیں اور موازنہ کریں:

netstat -ib | grep utun4

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

جب utun بالکل نظر نہ آئے

کامیاب دکھنے والے لاگ اِن کے بعد انٹرفیس کی فہرست خالی ہو تو عام طور پر یہ مطلب ہے کہ سرنگ شروع ہی نہیں ہوئی، ifconfig یہ نہیں کہ وہ اسے چھپا رہا ہے۔ کلائنٹ کی اپنی حالت دیکھیں، پھر نظام کی: کبھی منظور نہ ہونے والا یا اپ ڈیٹ کے بعد macOS نے بند کر دیا ہوا Network Extension پیچھے کوئی انٹرفیس نہیں چھوڑتا۔ منظوری System Settings میں، Login Items & Extensions کے تحت ہوتی ہے، اور وہاں پڑا پرانا اندراج کچھ بھی دوبارہ نصب کرنے سے پہلے ایک بار پھر ٹوگل کرنے کے لائق ہے۔

utun کی نمبر شماری دوبارہ جڑنے پر مستحکم نہیں رہتی۔ آپ کو utun5 مل سکتا ہے وہاں جہاں utun4 دس منٹ پہلے موجود تھا، کیونکہ پرانا انٹرفیس توڑا جاتا ہے اور کرنل اگلا خالی اشاریہ دیتا ہے۔ نام کو سختی سے لکھنے والی اسکرپٹیں اُس لمحے خاموشی سے ٹوٹ جاتی ہیں; اس کے بجائے پتے یا راستے پر ملائیں۔

پڑھنے والا پہلو صرف-پڑھنے کے قابل رکھیں۔ sudo ifconfig utun4 down سرنگ میں خلل ڈالتا ہے، اور پوری سرنگ والے پروفائل پر یہ آپ کا دور دراز سیشن بھی ساتھ لے جاتا ہے، جو صرف شواہد جمع کرتے وقت برا سودا ہے۔ یہاں درکار کسی چیز کو root نہیں چاہیے: جھنڈے، پتے اور کاؤنٹر پڑھنا آپ کے عام صارف سے چلتا ہے۔

اگلی بار جب Mac کی سرنگ غلط برتاؤ کرے تو جانچیں ترتیب سے کریں: ifconfig -l سے تصدیق کریں کہ utun آیا، اس کے جھنڈے، پتے اور MTU پڑھیں، اسے کسی عمل سے منسوب کریں، route -n get سے پوچھیں کہ منزل کون سا انٹرفیس استعمال کرتی ہے، پھر netstat -ib کی حرکت دیکھیں۔ ہر قدم الگ تہہ خارج کرتا ہے، اور پہلا غلط آنے والا مرحلہ ہی درستی کی جگہ ہے۔