ifconfig-noexec آپ کا SSH سیشن نہیں بچائے گا: یہ اصل میں کیا کرتا ہے
یہ OpenVPN کی اپنی انٹرفیس ایڈریس ترتیب کو دباتا ہے۔ یہ SSH کے لیے جواب کا راستہ محفوظ نہیں کرتا، تمام راستہ تبدیلیاں بند نہیں کرتا اور غائب ایڈریس فراہم نہیں کرتا۔
کسی فورم تھریڈ میں، ifconfig-noexec اسے وہ حل بتایا جاتا ہے جو ٹنل کے اوپر آنے پر SSH سیشن کو زندہ رکھتا ہے۔ یہ استدلال اس وقت تک معقول لگتا ہے جب تک آپ یہ نہ دیکھیں کہ یہ آپشن اصل میں کس چیز کو چھوتا ہے۔ یہ OpenVPN کو ٹنل انٹرفیس کا ایڈریس ترتیب دینے سے روکتا ہے اور وہ اقدار اس کے بجائے اسکرپٹس کو دیتا ہے؛ آپ کے انتظامی کنکشن کے جوابات کہاں جاتے ہیں اس بارے میں یہ کچھ نہیں کہتا۔ اس کے برعکس یقین رکھنا ایسی ٹنل بناتا ہے جس کا کوئی قابل استعمال ایڈریس نہ ہو اور SSH سیشن جو پھر بھی مر جاتا ہے۔
یہ آپشن اصل میں کیا سونپتا ہے
بطور طے شدہ، کلائنٹ ٹنل ڈیوائس کو اوپر لاتا ہے اور وہ مقامی اور دور دراز ایڈریس مقرر کرتا ہے جو سرور نے اسے دیے۔ جب ifconfig-noexec مقرر ہو تو وہ مرحلہ چھوڑ دیا جاتا ہے اور طے شدہ اقدار اسکرپٹ ماحول میں برآمد کر دی جاتی ہیں تاکہ کوئی اور انہیں لاگو کر سکے۔
ملکیت بدل جاتی ہے۔ اس کی جگہ کوئی نئی چیز نہیں بنائی جاتی۔
چنانچہ یہ آپشن جس سوال کا جواب دیتا ہے وہ یہ ہے کہ انٹرفیس کون ترتیب دیتا ہے، اور جس سوال کا جواب نہیں دیتا وہ یہ ہے کہ پیکٹ آپ تک واپس کیسے پہنچتے ہیں۔ ان دونوں کو الگ رکھیں، ورنہ بغیر ایڈریس والے انٹرفیس کی تلافی کے لیے آپ پوری شام راستے ترمیم کرتے رہیں گے۔
مختلف کاموں والے تین ملتے جلتے آپشن
اس خاندان کو الجھانا آسان ہے کیونکہ نام ایک لفظ سے مختلف ہیں اور علامات ایک دوسرے پر چڑھتی ہیں۔ کوئی بھی چننے سے پہلے پڑھیں کہ ہر ایک کیا دباتا ہے۔
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
یہ الگ الگ سمجھنے کے متبادل ہیں، ایک ساتھ چپکانے کا مجموعہ نہیں۔ ایڈریس ترتیب دبانے سے راستہ تبدیلیاں، فائر وال قواعد یا DNS لے جانے والے دھکیلے گئے آپشن نہیں دبائے جاتے۔ سونپا گیا اسکرپٹ بھی راستے بدلنے میں آزاد ہے، اور یہ ایسا فیصلہ ہے جو آپ ٹالنے کے بجائے سونپ رہے ہیں۔
اگر کسی وینڈر کا کلائنٹ انجن کو لپیٹتا ہے تو پروفائل میں نچلی سطح کی ہدایت ڈال کر یہ امید کرنے کے بجائے کہ ریپر اس کا احترام کرے گا، اس کا معاون انضمام استعمال کریں۔ ریپر اکثر کنیکٹ ہوتے وقت پروفائل دوبارہ بناتے ہیں، اس لیے ہاتھ سے کی گئی تبدیلی بغیر نقص کے غائب ہو جاتی ہے۔ فائل پر پوری شام لگانے سے پہلے دیکھیں کہ کلائنٹ اپنی ترتیبات کہاں رکھتا ہے۔ یہ جدول کی ہر قطار پر لاگو ہوتا ہے، صرف اس پر نہیں جس کے لیے آپ آئے۔
وہ SSH سیشن جسے آپ بچانا چاہتے تھے
SSH کنکشن کا ایک ماخذ ایڈریس، ایک منزل ایڈریس اور ایک جوابی راستہ ہوتا ہے۔ ایسے سرور پر جس نے ابھی مکمل ٹنل کا طے شدہ راستہ نصب کیا ہے، آپ کے عوامی ایڈریس کا جواب ٹنل سے مطابقت رکھتا ہے اور VPN گیٹ وے اسے گرا دیتا ہے۔
ٹنل انٹرفیس کی ایڈریس ترتیب میں کوئی چیز یہ نہیں بدلتی۔
اسے درست کرتا ہے ٹنل سے پہلے کے گیٹ وے کے ذریعے آپ کے انتظامی ایڈریس کے لیے زیادہ مخصوص راستہ، یا ایسا پالیسی قاعدہ جو اس ٹریفک کو موڑ دے، نیز وہ فلٹر ترتیبات جو آپ کا ہوسٹ لاگو کرتا ہے۔ دونوں مسائل کبھی کبھی ساتھ ظاہر ہوتے ہیں، اور اسی طرح ایک کو دوسرے کا علاج سمجھ لیا جاتا ہے۔ انہیں الگ الگ جانچیں: آپشن کے بغیر ٹنل اوپر لائیں، انٹرفیس کا ایڈریس اور جوابی راستہ دیکھیں، پھر فیصلہ کریں کہ دونوں میں سے کون واقعی خراب ہے۔
سونپے گئے اسکرپٹ کو کیا سنبھالنا ہوتا ہے
اگر آپ واقعی چاہتے ہیں کہ کوئی اور مالک انٹرفیس ترتیب دے تو کام کی فہرست بنائیں: مقامی اور دور دراز ایڈریس لاگو کریں، ڈیوائس اوپر لائیں، الگ کرتے وقت ایڈریسنگ بحال یا ہٹائیں، اور دوبارہ جڑنے کے بعد وہی دوبارہ کریں۔ ایک کامیاب سیشن کی اقدار کو سخت کوڈ نہیں کرنا چاہیے، کیونکہ سرور اگلی بار دوسرا جوڑا دے سکتا ہے۔
کلائنٹ جو ماحول کے متغیرات برآمد کرتا ہے وہی اس کام کے لیے واحد معاون ان پٹ ہیں۔
env | grep -E '^ifconfig_|^route_'کسی route-up اسکرپٹ کے اندر وہ متغیرات دستیاب ہوتے ہیں؛ cron کام یا ہاتھ سے چلائے گئے شیل سے نہیں۔ تصدیق کریں کہ آپ کا ورژن کون سا لائف سائیکل ہک استعمال کرتا ہے اور یہ بھی کہ ہک انٹرفیس بدلنے کے لیے کافی اختیارات کے ساتھ چلتا ہے، کیونکہ کلائنٹ پہلے ہی غیر مراعات یافتہ صارف پر اتر چکا ہو سکتا ہے۔
ایک سیشن نہیں، پورا لائف سائیکل جانچیں
ٹنل اوپر لائیں، ڈیوائس پر ایڈریس دیکھیں، پھر دوبارہ جڑیں اور پھر دیکھیں۔ جو ترتیب ایک بار چل کر دوسری کوشش میں ناکام ہو جائے اس کا مطلب عام طور پر یہ ہوتا ہے کہ سونپا گیا مرحلہ صرف پہلے کنکشن پر چلتا ہے۔
پھر دونوں قبولیت کے معیار ساتھ جانچیں: مطلوبہ انتظامی راستے سے نیا SSH کنکشن چلتا ہے، اور اجازت یافتہ ایپلیکیشن ٹنل صحیح استعمال کرتی ہے۔
ٹنل کا ایڈریس نہ ہونے کے باوجود پرانا SSH سیشن اتفاقاً زندہ رہنا کامیابی نہیں ہے، اور جب کوئی کام نہ سنبھالے تو یہ آپشن بالکل یہی حالت پیدا کرتا ہے۔ پہلے انٹرفیس کا ایڈریس، پھر انتظامی جوابی راستہ، پھر ایپلیکیشن دیکھیں۔ اگر تین میں سے دو غلط ہوں تو آپشن نے کام تو ہٹایا مگر اسے مالک نہیں دیا۔