سبز آئیکن، وہی عوامی IP: VPN نے کون سا راستہ چھوڑا

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

کلائنٹ نے اصل میں کیا نصب کیا

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

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

انتخابی روٹنگ کی تین صورتیں

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

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

دوسرا سرا ماخذ پتہ دوبارہ لکھنا ضروری ہے

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

وہ انٹرفیس نام لیں جو واقعی انٹرنیٹ کی طرف ہے، جو جدید ڈسٹری بیوشن میں ہمیشہ eth0 نہیں ہوتا۔ مقررہ پتے والا ہوسٹڈ سرور masquerade استعمال کرنے کے بجائے براہ راست اس پتے پر ترجمہ کر سکتا ہے۔ دونوں حصے اہم ہیں، کیونکہ ترجمے کے بغیر آگے بھیجنا ناقابلِ روٹ ماخذ لیک کرتا ہے، جبکہ آگے بھیجے بغیر ترجمہ پیکٹ کو کبھی نہیں دیکھتا۔

نام کا حل اپنا راستہ لیتا ہے

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

resolvectl status | head -20
resolvectl query example.org

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

فیصلہ کرنے والے چار مشاہدے

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

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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