OpenVPN کی دھکیل کردہ راہیں نصب نہیں ہوتیں: وقت، حقوق یا پالیسی

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

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

ثابت کریں کہ راہ موجود نہیں، صرف ٹوٹی ہوئی نہیں

شروع اس بات سے کریں کہ راہ ٹوٹی نہیں بلکہ موجود نہیں۔ Linux پر، ip route show dev tun0 بتاتا ہے کہ کلائنٹ نے ٹنل آلے پر کیا نصب کیا۔ Windows پر، route print یا Get-NetRoute وہی چیز جدول کی شکل میں دکھاتا ہے۔

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

وقت: اضافہ آلے کے وجود سے پہلے چلا

کنٹرول چینل بلند ہونے کے بعد اور انٹرفیس کنفیگر کرنے کے بعد کلائنٹ سرور کے PUSH_REPLY کا تجزیہ کرتا ہے۔ تبھی وہ راؤٹنگ جدول کو چھوتا ہے، پلیٹ فارم کی فراہم کردہ کسی بھی طریقے سے۔ Linux netlink سے گزرتا ہے؛ Windows ایک API استعمال کرتا ہے جس کے لیے بلند ٹوکن درکار ہے۔ کنفیگریشن پڑھتے ہی راہیں شامل کرنے والا اسکرپٹ یا کلائنٹ TUN/TAP آلے کے وجود سے پہلے چل سکتا ہے، اور کرنل اضافہ مسترد کر دیتا ہے۔

یہی دوڑ بتاتی ہے کہ ہاتھ سے لکھی راہ کیوں کام کرتی ہے مگر خودکار نہیں: جب آپ اسے لکھتے ہیں، انٹرفیس پہلے ہی بلند ہوتا ہے۔

اسی صورت کے لیے route-delay موجود ہے، اور route-up ایسے اسکرپٹ کا نام دیتا ہے جو انٹرفیس اور راہیں کنفیگر ہونے کے بعد چلتا ہے۔ ٹنل پتے پر منحصر راہیں ابتدائی مرحلے میں نہیں، اسی ہک میں رکھیں۔

حقوق: جدول کون بدل سکتا ہے

Windows راؤٹنگ جدول بدلنے کے لیے بلند ٹوکن درکار ہے۔ عام صارف کا شروع کردہ GUI سروس کے ذریعے اڈاپٹر کا پتہ مقرر کر سکتا ہے اور پھر بھی راہ شامل نہیں کر سکتا۔ تب لاگ گم شدہ دھکیل کے بجائے رسائی مسترد ہونے کی طرز کی خرابی دکھاتا ہے۔

GUI کو منتظم کے طور پر شروع کرنا، یا سروس پر مبنی کلائنٹ استعمال کرنا، وہ نتیجہ بدل دیتا ہے۔ مطلوبہ ٹوکن کے بغیر کلائنٹ شروع کرنے والا شیڈول شدہ کام ایسا نہیں کرتا۔

کچھ بھی بدلنے سے پہلے دیکھیں کہ کلائنٹ واقعی کس اکاؤنٹ پر چلتا ہے۔ ورژن اور سروس موڈ طے کرتے ہیں کہ کون سی وجوہات ممکن ہیں، لہٰذا دونوں کو راہ کی آؤٹ پٹ کے ساتھ لکھ لیں۔

پالیسی: دھکیل کردہ راہیں جان بوجھ کر چھوڑی جا سکتی ہیں

route-nopull کلائنٹ کو سرور کی دھکیل کردہ راہیں نظرانداز کرنے پر مجبور کرتا ہے، بشمول دھکیل کردہ ڈیفالٹ راہ، جبکہ ٹنل پتہ اب بھی قبول کیا جاتا ہے۔ دھکیلے گئے DNS اور DHCP اختیارات اسی ہدایت سے چھوڑ دیے جاتے ہیں۔ ایسا کلائنٹ معیوب نہیں؛ وہ اپنی کنفیگریشن میں واضح راہ کی سطریں توقع کرتا ہے۔

route-noexec الگ کنٹرول ہے: یہ کلائنٹ کو راہ کی تبدیلیاں سرے سے نافذ کرنے سے روکتا ہے۔ وہ ٹوپولوجی جس کا کلائنٹ نقشہ نہیں بنا سکتا، ویسا ہی نتیجہ دے سکتی ہے، اور راہ شامل ہونے کے بجائے مسترد شدہ کے طور پر درج ہوتی ہے۔ تینوں میں سے کون لاگو ہے، اندازہ لگانے کے بجائے فیصلہ بتانے والی لاگ سطر پڑھیں۔ پھر مؤثر پروفائل جانچیں، کیونکہ درآمد کنندہ یا انتظامی آلہ ایسے اختیارات شامل کر سکتا ہے جو صارف نے کبھی ترمیم نہیں کیے۔

متن ایڈیٹر میں صاف دکھنے والا پروفائل رن ٹائم میں شامل کردہ ہدایت رکھ سکتا ہے۔

دھکیل فہرست کا جدول سے موازنہ کریں

جڑنے کے بعد سرور کی دھکیل فہرست کلائنٹ کے جدول کے پاس رکھیں۔ Linux پر وہ ip route show dev tun0 ہے؛ Windows پر route print یا Get-NetRoute۔ اگر راہ موجود نہیں تو پہلے تنصیب درست کریں۔ اگر موجود ہے مگر ٹریفک ناکام ہوتا ہے تو فارورڈنگ اور فائر وال پالیسی کی طرف جائیں۔

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