کیا ٹریفک واقعی VPN سے گزر رہی ہے؟ اس کی تصدیق کیسے کریں
روٹ کی تلاش، پہلا ہاپ، فزیکل اڈاپٹر پر کیپچر اور باہر سے پتے کی جانچ سوال کے مختلف حصوں کا جواب دیتے ہیں۔
سسٹم ٹرے کے آئیکن سے دو خرابیاں ایک جیسی دکھتی ہیں: وہ ٹریفک جو سرنگ میں داخل ہوتی ہے اور وہ جو خاموشی سے اسے نظرانداز کر جاتی ہے۔ کلائنٹ دونوں صورتوں میں Connected دکھاتا ہے، کیونکہ Connected کا مطلب صرف یہ ہے کہ سرنگ کا انٹرفیس موجود ہے اور کلائنٹ نے مطلوبہ روٹس نصب کر لیے ہیں۔ یہ کہ کسی ایک ایپلیکیشن کے ایک پیکٹ نے وہ روٹس استعمال کیے یا نہیں، الگ سوال ہے جس کا جواب اسٹیک میں کہیں اور دیا جاتا ہے۔ چار پیمائشیں اس کا بیشتر حصہ حل کرتی ہیں — روٹ کی تلاش، پہلا ہاپ، فزیکل اڈاپٹر پر کیپچر اور باہر سے مشاہدہ — اور سرور کا اپنا سیشن منظر باقی ڈھانپ لیتا ہے۔
اس روٹ سے شروع کریں جس پر پیکٹ جائے گا
روٹنگ ٹیبل ہی فیصلہ ہے، اس لیے پوری پڑھ کر اندازہ لگانے کے بجائے اس سے ایک منزل کے بارے میں پوچھیں۔ Linux پر، ip route get وہ انٹرفیس اور ماخذ پتہ بتاتا ہے جو کرنل نے چنا:
ip route get 203.0.113.10
ip route get 10.20.5.7Windows پر، Find-NetRoute -RemoteIPAddress 203.0.113.10 route print -4 سے زیادہ مفید ہے، اسی وجہ سے: یہ جیتنے والے روٹ کی اطلاع دیتا ہے، تمام موجود روٹس کی نہیں۔ پھر بھی اس کی 0.0.0.0 قطار کے لیے ٹیبل ایک بار پڑھیں۔ وہاں /1 جوڑا ہونے کا مطلب ہے کہ مکمل سرنگ کلائنٹ نے ڈیفالٹ روٹ دوبارہ لکھا ہے: OpenVPN کا redirect-gateway def1 آپشن سرنگ کے ذریعے 0.0.0.0/1 اور 128.0.0.0/1 نصب کرتا ہے، جو فزیکل ڈیفالٹ کو حذف کیے بغیر طویل ترین سابقہ مماثلت میں موجود 0.0.0.0/0 کو ہرا دیتا ہے۔ اسی لیے دو ڈیفالٹ روٹس ساتھ رہ سکتے ہیں جبکہ سب کچھ پھر بھی سرنگ میں جاتا ہے۔
دو تفصیلیں ٹیبل کو جھوٹا بناتی ہیں۔ پہلی، ڈیفالٹ روٹس کی تعداد نہیں بلکہ مماثل سابقہ دیکھیں، کیونکہ انٹرفیس میٹرک یا /1 جوڑا جیتنے والا طے کرتا ہے۔ دوسری، پہلے سے موجود کنکشن اسی راستے پر رہتا ہے جس سے قائم ہوا تھا؛ سرنگ اٹھنے کے بعد کھلا سیشن ری سیٹ ہونے تک پرانا روٹ استعمال کر سکتا ہے، اور اسی لیے دوبارہ جڑنا روٹنگ مسئلہ درست کرتا دکھتا ہے۔ چلتا ہوا کلائنٹ — ps ax | grep openvpn — صرف یہ ثابت کرتا ہے کہ عمل شروع ہوا۔
ایک اندرونی اور ایک عوامی نام کا سراغ لگائیں
روٹ کی تلاش ارادہ دکھاتی ہے؛ راستہ ترسیل دکھاتا ہے۔ جڑے ہونے کی حالت میں اس نام کا سراغ لگائیں جو لازمی اندرونی ہو اور اس نام کا جو نہ ہو، اور پہلے ہاپ کا موازنہ کریں:
traceroute intranet.corp.example
traceroute 1.1.1.1دونوں کے لیے ایک ہی پہلا ہاپ مطلب یہ ہے کہ اندرونی نام کبھی سرنگ میں داخل نہیں ہوا اور خرابی اس کے اوپر ہے، عام طور پر ایسا نام جو عوامی پتے میں حل ہوتا ہے یا ایسا روٹ جو کبھی نصب نہیں ہوا۔ اگر اندرونی ٹریفک 10.8.0.1 سے باہر جاتی ہے اور عوامی 192.168.1.1 سے، تو منقسم سرنگ وہی کر رہی ہے جس کے لیے ترتیب دی گئی تھی۔ VPN گیٹ وے تک پہنچ کر صرف وقت ختم ہونے واپس کرنے والا نقش عام طور پر واپسی راستے یا سرور فائر وال کا مسئلہ ہے، گمشدہ فارورڈ روٹ نہیں۔
فلٹر شدہ ICMP اس جانچ کو جھوٹا بناتا ہے: دونوں نقشوں پر ستارے مردہ سرنگ جیسے دکھتے ہیں اور عام طور پر وہ فائر وال ہوتا ہے۔ جہاں ممکن ہو TCP پورٹ آزمائیں — Linux پر traceroute -T -p 443 — اور یاد رکھیں کہ نقش یہ نہیں بتاتا کہ کون سے حل کنندہ نے جواب دیا: نام مقامی طور پر حل ہو کر بھی سرنگ سے قابل رسائی ہو سکتا ہے۔
سرنگ پر نہیں، فزیکل اڈاپٹر پر کیپچر کریں
فزیکل لنک واحد جگہ ہے جو دکھاتی ہے کہ نیٹ ورک واقعی کیا دیکھتا ہے۔ سرنگ اٹھی ہونے پر دفتر جانے والا سیشن VPN سرور کو مخاطب خفیہ پے لوڈ کے طور پر نظر آنا چاہیے، 10.20.5.7 سے کنکشن کے طور پر نہیں:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5پہلا فلٹر مقامی طور پر باہر جانے والا نام حل پکڑتا ہے، جو سب سے عام اور سب سے خاموش رساؤ ہے — صفحہ پھر بھی لوڈ ہوتا ہے، حل کنندہ نے صرف استفسار دیکھا۔ دوسرا سرنگ کے اندر ہی ہونے والی اندرونی پتے کی عام ٹریفک پکڑتا ہے۔ Windows پر، pktmon بغیر ڈرائیور وہی کام کرتا ہے: pktmon filter add -p 53، پھر pktmon start --capture --pkt-size 128، پھر pktmon stop اور pktmon format pktmon.etl -o capture.txt۔ یہ جھنڈے Windows ورژنز میں قدرے مختلف ہیں، اس لیے نحو پر بھروسہ کرنے سے پہلے pktmon filter add /? دیکھیں۔
رساؤ تلاش کرنے کے لیے فزیکل انٹرفیس پر کیپچر کریں؛ سرنگ پر کیپچر وہ پیکٹ رکھتا ہے جن کے بارے میں آپ پہلے سے مانتے ہیں کہ وہاں ہیں، اور سرور پر یہ ناقابلِ مطالعہ بیرونی پیکٹ رکھتا ہے جن کا ماخذ گیٹ وے ہے۔ کسی بھی انٹرفیس کے بائٹ کاؤنٹر پیکٹ بیان کرتے ہیں، پروگرام نہیں؛ ٹریفک کو عمل سے منسوب کرنے کے لیے ایسا مانیٹر درکار ہے جو ساکٹ کو عمل سے منسلک کرے۔
باہر کی سروس سے پوچھیں، پھر ہر ایپلیکیشن کے لیے دوبارہ پوچھیں
خروج ثابت کرنے والی واحد جانچ باہر سے آیا جواب ہے: ایسی سروس جو اپنا دیکھا ہوا ماخذ پتہ واپس دے۔ اسے شیل سے چلائیں، جہاں انٹرفیس منتخب کر سکیں، اور دو بار چلائیں:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipمختلف جواب دونوں راستوں کا ثبوت اور مخصوص ایپلیکیشن جانچنے کا طریقہ دیتے ہیں: اسے بائنڈ کریں، یا ایک روٹ والے نیٹ ورک نام فضا میں چلائیں، اور دیکھیں دور کا سرا کون سا پتہ ریکارڈ کرتا ہے۔ یکساں جواب دلچسپ خرابی ہے: یا بائنڈنگ اثر نہ کر سکی، یا میزبان اور دور کے سرے کے درمیان کچھ پہنچنے سے پہلے ماخذ پتہ دوبارہ لکھ دیتا ہے۔ Windows پر، curl --interface اڈاپٹر کا نام نہیں، پتہ مانگتا ہے۔
VPN پتہ بتانے والا براؤزر اس براؤزر کو ثابت کرتا ہے۔ میل کلائنٹ، پیکیج مینیجر، بیک اپ ایجنٹ یا دوسری براؤزر پروفائل ہر ایک مختلف راستہ لے سکتے ہیں، خاص طور پر جب پراکسی سیٹنگ یا منقسم سرنگ کا روٹ ان میں سے کسی کو ڈھانپ لے۔ پتہ بدلنا بذات خود رساؤ کا ثبوت نہیں: لوڈ بیلنسر دیکھے گئے اخراج کے مطابق مختلف جواب دے سکتا ہے، اس لیے صفحہ نہیں بلکہ ریکارڈ شدہ ماخذ پتہ کا موازنہ کریں۔
ساتھی کی تصدیق کے لیے سرور کا منظر استعمال کریں
سرور دوسرے سوال کا جواب دیتا ہے: کیا ساتھی جڑا ہے، کتنا منتقل کیا اور کیا سیشن دوبارہ شروع ہوا۔ سرور پر ساتھی فعال ہو جبکہ کلائنٹ کے کاؤنٹر بمشکل حرکت کریں، تو اس کا مطلب ہے کہ ایپلیکیشن کی ٹریفک سرنگ میں نہیں جا رہی، کلائنٹ ٹیبل کچھ بھی کہے۔ اور ایسا ساتھی جو کچھ کام نہ کرنے کی شکایت کرنے والے صارف کے لیے بہت ڈیٹا منتقل کرے، وہ الگ تفتیش ہے۔
یہاں دو جال ہیں۔ نقاب پوش سرنگ ہر بہاؤ کو گیٹ وے سے آیا ہوا دکھاتی ہے، اس لیے لاگ اور فی کلائنٹ حساب ایک ہی پتے پر سمٹ جاتے ہیں۔ اور کلائنٹ کو مقامی میزبان سمجھا جاتا ہے، اس لیے کسی کے VPN سے فائلیں نقل کرنے کے سوال کا جواب سرور پر فائل شیئرنگ ٹریفک یا سرور پر میزبان آڈٹ دیتا ہے — سرنگ دیکھنے سے سرے اور حجم ملتا ہے، فائل نام نہیں۔
ڈیزائن فیصلے کو رساؤ سے الگ کریں
سرنگ سے باہر سب کچھ رساؤ نہیں۔ لنک-مقامی اور نشریاتی ٹریفک ڈیزائن کے مطابق مقامی رہتی ہے، ملٹی کاسٹ سے ملی پرنٹر LAN پر اعلان جاری رکھتا ہے، اور DHCP کو مقامی طور پر باہر جانا ہوتا ہے۔ کسی مخصوص انٹرفیس سے بندھی ایپلیکیشن جان بوجھ کر روٹنگ ٹیبل سے گزرتی ہے، اور اسے صرف فائر وال اصول، نام فضا یا پالیسی روٹ بدلتا ہے۔
IPv6 چیک لسٹ میں اپنی الگ سطر کا حقدار ہے۔ صرف IPv4 لے جانے والی سرنگ دوہرے اسٹیک میزبان کو دوسرا قابل استعمال راستہ چھوڑ دیتی ہے، اور دوہرا اسٹیک منزل اسی کو ترجیح دے گی — DNS بھی، اگر حل کنندہ IPv6 سے قابل رسائی ہو۔ IPv4 نتیجے کو مکمل ماننے سے پہلے اڈاپٹر پر IPv6 بند کریں یا تصدیق کریں کہ سرنگ اسے لے جاتی ہے۔
جب جانچیں نہ ملیں، تو فرق ہی عام طور پر خرابی کا نام بتاتا ہے:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
کام کرنے والا ترتیب: جڑنے سے پہلے اور بعد روٹنگ ٹیبل محفوظ کریں، ایک اندرونی اور ایک عوامی نام کا سراغ لگائیں، فزیکل اڈاپٹر پر DNS کیپچر کریں، مخصوص ایپلیکیشن کے لیے شیل سے خروج کا پتہ واپس لیں، پھر حجم کے لیے سرور پڑھیں۔ اگر پہلے چار مل جائیں، سرنگ وہی لے جا رہی ہے جو آپ سمجھتے ہیں اور باقی مسئلہ اس کے اوپر ہے۔ اگر ان میں سے دو نہ ملیں، تو نہ ملنے والا جوڑا ہی خرابی ہے، آئیکن نہیں۔