آپ کی .ovpn فائل کوڈ چلا سکتی ہے، صرف ٹریفک روٹ کرنے کے لیے نہیں
up یا down مددگار کا نام دینے والی پروفائل آپ کے اختیارات کے ساتھ کوڈ چلاتی ہے۔ راستہ، ملکیت، صفائی اور script-security ترتیب جانچیں۔
زیادہ تر لوگ .ovpn فائل کو ویسے پڑھتے ہیں جیسے راؤٹر کے ترتیبات کے صفحے کو پڑھتے ہیں: پتے، راستے، سائفرز کی فہرست۔ کوڈ چلانے والا حصہ نیچے کی طرف بیٹھتا ہے، پلمبنگ کے کام جیسی نظر آنے والی ہدایات کے پاس، اور یہ اسی اختیار کے ساتھ چلتا ہے جو کلائنٹ کے پاس پہلے سے ہے۔ یہی وہ خلا ہے جس سے لاپرواہ یا بدنیت پروفائل فائدہ اٹھاتا ہے، اور یہی وہ خلا ہے جو ایک مفید DNS مددگار کو تین ہفتے بعد سپورٹ مسئلے میں بدل دیتا ہے۔ ایونٹ ہدایت، سیکیورٹی سطح اور فائل کی ملکیت طے کرتے ہیں کہ کیا ہو سکتا ہے؛ اسکرپٹ کا مواد طے کرتا ہے کہ واقعی کیا ہوتا ہے۔ جڑنے سے پہلے چاروں پڑھیں۔
مددگار چلانے والا پروفائل ایک پروگرام ہے، ترتیبات کی فائل نہیں
route اور dhcp-option جیسی ہدایات اس حالت کو بیان کرتی ہیں جو کلائنٹ کو قائم کرنی چاہیے، اور کلائنٹ انہیں ڈیٹا ہی سمجھتا ہے۔ up اسکرپٹ مختلف ہے: کلائنٹ اسے عمل کے طور پر شروع کرتا ہے اور اسے کنکشن کی تفصیلات سے بھرا ماحول دیتا ہے، اس لیے مصنف نے جو کچھ لکھا وہ آپ کے اکاؤنٹ کے حقوق کے ساتھ چلتا ہے۔ جس لیپ ٹاپ میں صارف منتظم ہے، وہاں منسلکہ یا فورم تھریڈ سے پیسٹ کی گئی فائل کے لیے یہ چوڑا دروازہ ہے۔ فرق اسلوب کا نہیں، یہ کنفیگریشن اور کوڈ کے درمیان فرق ہے۔
جس افسانے کو چھوڑ دینا چاہیے وہ یہ ہے کہ پروفائل صرف ٹریفک کو موڑ سکتا ہے۔ ip route add چلانے والا مددگار اور دور کے میزبان کے خلاف curl چلانے والا مددگار ایک ہی طریقہ کار ہیں، اور پروفائل باہر سے ایک جیسی دکھتی ہے۔ فائل کی شکل میں کوئی چیز نہیں بتاتی کہ آپ کے پاس کون سی ہے، اس لیے جائزہ اسکرپٹ تک پہنچنا ضروری ہے۔
حقیقت میں عمل درآمد کیا طے کرتا ہے، اور قابل بنانے والی سطریں کیسی دکھتی ہیں
تین چیزیں مددگار کو کنٹرول کرتی ہیں: اسے نام دینے والی ایونٹ ہدایت، اسے اجازت دینے والی script-security سطح، اور کلائنٹ پلیٹ فارم کا اپنا نفاذ۔ پروفائل ہک مانگ سکتی ہے اور پھر بھی کچھ ہوتا نہیں دیکھ سکتی، کیونکہ موبائل کلائنٹ یا کٹا ہوا ڈیسک ٹاپ بلڈ اس ایونٹ کو بالکل نافذ نہ کرے۔ اسی طرح، اپنے کام کی ضرورت سے زیادہ اجازت مانگنے والی پروفائل اپنی اصل کے بارے میں کچھ بتاتی ہے۔ اجازت کی سطح ایک صلاحیت ہے، منظوری نہیں۔ قابل بنانے والی سطریں ایسی دکھتی ہیں، راستہ آپ کے راستے کی جگہ لیتا ہے۔
script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.shسطح 0 بیرونی پروگراموں کو مسترد کرتی ہے اور سطح 1، جو ڈیفالٹ ہے، صرف کلائنٹ کی اندرونی قابلِ عمل فائلوں کی اجازت دیتی ہے، اس لیے ہک کو 2 یا زیادہ چاہیے؛ سطح 3 بنیادی طور پر پرانے پاس ورڈ منتقل کرنے کے لیے ہے اور اس سے بچنا بہتر ہے۔ ہک کے ساتھ بھیجی گئی پروفائل کو ہدایت اور وہ سطح دونوں چاہیے، اس لیے فائل کے نچلے حصے کی ایک سطر سرٹیفکیٹ بلاک جتنی ہی جانچ کی حقدار ہے۔ OpenVPN کا دستورالعمل اجازت کی سطحوں کی فہرست دیتا ہے، اور اس کی عبارت پروفائل کی اصل مانگ کے ساتھ پڑھنے کے لائق ہے۔
ملکیت، راستہ اور مددگار کو کیا کھلایا جاتا ہے
آپ کا بھروسہ رکھنے والی پروفائل جو ایسی اسکرپٹ کی طرف اشارہ کرتی ہے جسے دوسرا اکاؤنٹ دوبارہ لکھ سکتا ہے، قابلِ اعتماد انتظام نہیں، کیونکہ کل کا جائزہ اب یہ بیان نہیں کرتا کہ آج کیا چل رہا ہے۔ مددگار کا مالک اور موڈ جانچیں، اور یقینی بنائیں کہ ترتیب دیا گیا راستہ اسی فائل تک پہنچتا ہے جس کا آپ نے جائزہ لیا، نہ کہ ایسے نام تک جسے کوئی اور ڈھانپ سکے۔ دلائل اور ماحول بھی اسی نظر کے حقدار ہیں: کلائنٹ ہک کو کنکشن کی تفصیلات دیتا ہے، اور اپنا سارا ماحول لاگ کرنے والا مددگار سپورٹ ٹکٹ میں اسناد لکھ رہا ہو سکتا ہے۔ آپریٹر یا پلیٹ فارم کے دستاویزی انضمام کو غیر متعلقہ پوسٹ سے کاپی کی گئی DNS اسکرپٹ پر ترجیح دیں، کیونکہ ایک ہی فائل پر جھگڑتے دو ریزولور منتظمین ایسی ناکامی پیدا کرتے ہیں جو ٹوٹے VPN جیسی دکھتی ہے۔
جب ناکام ہک کی رپورٹ کریں، تو کہیں بھی پیسٹ کرنے سے پہلے ماحول کو ترمیم کریں۔ ڈی بگ میں مدد کرنے والا ڈمپ وہ ٹوکن بھی لے جا سکتا ہے جو آپ کی تصدیق کرتا ہے۔
صفائی کی ناکامیاں سرنگ جانے کے بعد ظاہر ہوتی ہیں
up مددگار راستے اور ریزولور ترتیبات شامل کرتا ہے، اور down مددگار کو وہ دوبارہ ہٹانی چاہئیں۔ جب down ہک نہ ہو، خاموشی سے ناکام ہو، یا کلائنٹ مارے جانے کی وجہ سے کبھی نہ چلے، تو بچا ہوا سامان سیشن سے زیادہ زندہ رہتا ہے۔ پھر ٹریفک ایسے راستے پر جاتا ہے جس کا کسی نے منصوبہ نہیں بنایا اور نام ایسے ریزولور سے حل ہوتے ہیں جسے ہٹایا جانا چاہیے تھا، جبکہ سرنگ خود صحت مند دکھتی ہے۔ یہ علامات منقطع ہونے کے بعد آتی ہیں، اس لیے قصوروار پروفائل کو نہیں، نیٹ ورک کو ٹھہرایا جاتا ہے۔
سرنگ اتارنے کو الگ مرحلے کے طور پر جانچیں: سرنگ اوپر لائیں، راستے اور ریزولور نوٹ کریں، نیچے اتاریں، پھر تصدیق کریں کہ دونوں گئے۔ صاف ستھرا جڑنے والی پروفائل بھی پیچھے حالت چھوڑ سکتی ہے، اور مددگار کا صفر ایگزٹ کوڈ یہ ثابت نہیں کرتا کہ ریزولور وہیں پہنچا جہاں آپ سوچتے ہیں۔
مددگار کا جائزہ اور راہِ فرار رکھنا
اسکرپٹ کو شروع سے آخر تک پڑھیں اور تین چیزیں تلاش کریں: اختیار مانگنے والے احکامات، ایسے سخت کوڈ شدہ راستے جو آپ کے نظام پر نہ ہوں، اور وہ کوئی بھی نیٹ ورک کال جو یہ کرتی ہے۔ پھر دیکھیں کہ یہ کیسے ناکام ہوتی ہے، کیونکہ غلطیاں نگلنے والا مددگار کنفیگریشن کی غلطی کو معمہ بنا دیتا ہے۔ اگر آپ ایک جملے میں نہیں بتا سکتے کہ اسکرپٹ کیا کرتی ہے اور اسے کون بدل سکتا ہے، تو آپ اسے فعال کرنے کے لیے تیار نہیں۔ وہ جملہ جتنا اختیار مانگتا ہے اس سے زیادہ مانگنے والی پروفائل رکنے کا اشارہ ہے۔
آخری چلنے والی پروفائل اور اس کے بتائے ہوئے مددگار کو محفوظ ذخیرے میں رکھیں، دونوں ورژن نوٹ کرتے ہوئے، تاکہ واپسی بدترین لمحے میں دوبارہ تعمیر نہ ہو بلکہ نقل ہو۔ اگر مددگار صرف ایسی تقسیم یا کلائنٹ ورژن کے لیے ہے جسے اس کی ضرورت نہیں رہی، تو غلطیاں رکنے تک اختیارات بڑھانے کے بجائے ترتیب کے مالک کنفیگریشن میں اسے ریٹائر کریں۔ یہی راہِ فرار ہے: کم چلنے والے حصے، زیادہ اجازت نہیں۔