Linux پر Kerio: kvnet کو وہ MAC دینا جس کی سرور توقع کرتا ہے
kvnet ہر اتصال پر دوبارہ بنتا ہے، اس لیے ایک بار کا پتہ کی تبدیلی ضائع ہو جاتی ہے۔ کلائنٹ نے جو قدر لاگ کی ہے اسے پڑھیں اور اتصال کے بعد ہک سے اسے لاگو کریں۔
تین چیزیں مطابقت رکھنی چاہئیں اس سے پہلے کہ Kerio سرنگ ٹریفک لے جائے: kvnet انٹرفیس پر پتہ، وہ قدر جو کلائنٹ نے لاگ کی، اور وہ جس کی سرور پالیسی یا DHCP توقع کرتی ہے۔ جب وہ مطابقت نہیں رکھتیں، سرنگ پھر بھی توثیق کرتی ہے اور پھر بھی اوپر آتی ہے، اور یہی ناکامی کو الجھا ہوا بناتا ہے۔ انٹرفیس ہر اتصال کے لیے بنایا جاتا ہے، اس لیے ہاتھ سے رکھا گیا پتہ صرف اسی سیشن کا ہے اور کسی اور کا نہیں۔ یہی مسئلے کی شکل ہے، اور حل ترتیب کی فائل نہیں بلکہ ہک ہے۔ باقی یہ ہے کہ قدر کہاں سے پڑھنی ہے اور کہاں لاگو کرنی ہے۔
پتہ بار بار واپس کیوں آتا ہے
kvnet ایک مجازی اڈاپٹر ہے جسے کلائنٹ اتصال شروع ہونے پر بناتا ہے اور ختم ہونے پر ہٹا دیتا ہے۔ اس لیے دستی ip link set بالکل اتنی ہی دیر رہتا ہے جتنی وہ سیشن رہتا ہے جس پر اسے لاگو کیا گیا، اور اگلا اتصال اسی سے شروع ہوتا ہے جو کلائنٹ مختص کرتا ہے۔ جس مشین پر کلائنٹ متوقع پتہ لاگو نہیں کر پاتا، وہاں ہر دوبارہ اتصال وہی عدم مطابقت پھر لے آتا ہے، اور لیز یا رسائی کا قاعدہ آلے کو پھر مسترد کر دیتا ہے۔
یہ نمونہ بذات خود تشخیصی ہے۔ ایک سیشن میں کام کرنے والی اور اگلے میں ناکام ہونے والی سرنگ اسناد کا مسئلہ نہیں ہے، کیونکہ اتصالوں کے درمیان اسناد تبدیل نہیں ہوتیں۔
قدر انٹرفیس سے نہیں، کلائنٹ سے پڑھیں
Linux کلائنٹ بات چیت کی تفصیلات اپنے ڈیبگ لاگ میں لکھتا ہے، اور وہ پتہ جو وہ استعمال کرنا چاہتا ہے وہاں اتصال کی ترتیب میں آخری پتے کی شکل کا ٹوکن بن کر ظاہر ہوتا ہے۔ اس کا موازنہ اس سے کریں جو کرنل واقعی رکھتا ہے، جو ایک readlink کی دوری پر ہے: cat /sys/class/net/kvnet/address۔
اگر دونوں مختلف ہوں تو کلائنٹ صحیح قدر جانتا تھا اور اسے لاگو نہیں کر سکا، اور انٹرفیس بننے کے بعد اسے لاگو کرنے والا ہک یہ خلا پاٹ دیتا ہے۔ اگر لاگ میں کوئی پتہ ہی نہ ہو تو مسئلہ پہلے کا ہے اور اسکرپٹ کا نہیں، کلائنٹ ورژن یا سرور پروفائل کا ہے۔
انٹرفیس بننے کے بعد اسے لاگو کریں
NetworkManager کے صارفین اس کی ڈسپیچر ڈائریکٹری میں اسکرپٹ رکھ سکتے ہیں اور صرف اسی وقت عمل کر سکتے ہیں جب VPN انٹرفیس اوپر آئے۔ systemd کے زیر انتظام کلائنٹ کو زیادہ احتیاط چاہیے: سروس شروع ہونے پر چلنے والا drop-in عام طور پر اڈاپٹر بننے سے پہلے ہی فعال ہو جاتا ہے، اس لیے ہک کو اڈاپٹر فرض کرنے کے بجائے انٹرفیس کا انتظار کرنا چاہیے۔ تب پتہ مقرر کریں، اور اگر لنک اوپر ہوتے ہوئے کرنل انکار کرے تو اسے نیچے لائیں، پتہ مقرر کریں اور دوبارہ اوپر لائیں۔ نکالا گیا ٹوکن ip link کو دینے سے پہلے MAC نمونے کے ذریعے دوبارہ پڑھیں، تاکہ غیر متوقع لاگ لائن دلیل نہ بن سکے۔
کلائنٹ کے لاگ سے root کے طور پر چلنے والی ہر چیز تنگ ملکیت کی حقدار ہے: root کی ملکیت والی فائل، دوسروں کے لیے ناقابل تحریر، اور تصدیق شدہ پتے سے آگے کوئی شیل انٹرپولیشن نہیں۔ نمونے کی جانچ اسکرپٹ کے اندر رکھیں۔ لاگ کے مواد کو یہ فیصلہ کرنے نہ دیں کہ کون سا حکم چلے گا۔
لنک نہیں، لیز کی تصدیق کریں
ip -4 -o addr show dev kvnet کو متوقع حد میں پتہ دکھانا چاہیے، ip neigh show dev kvnet کو گیٹ وے دکھانا چاہیے، اور VPN کے پیچھے ایک سروس کو جواب دینا چاہیے۔ پھر ایک بار منقطع ہو کر دوبارہ منسلک ہوں؛ اگر پتہ واپس آئے تو ہک غلط واقعے پر چل رہا ہے یا بالکل نہیں چل رہا۔
جو انٹرفیس صحیح پتے کے ساتھ ظاہر ہو اور کبھی لیز نہ پائے وہ سرور کی طرف اشارہ کرتا ہے۔ یہ دوسری جانچ ہے اور عام طور پر دوسری ٹیم۔ ہک کو دوبارہ ترمیم کرنے سے پہلے تصدیق کریں کہ اکاؤنٹ کو اجازت ہے اور پول کے پاس اب بھی پتہ ہے۔
اپ گریڈ کے بعد ورک اراؤنڈ پر نظر ثانی کریں
جو کلائنٹ بلڈ پتہ درست طریقے سے مقرر کرتا ہے وہ آپ کے ہک کو پرانی قدر لاگو کرنے پر چھوڑ دیتا ہے، جو کسی اصلاح کی لائی ہوئی نئی خرابی ہے۔ کسی دوسری مشین یا فورم پوسٹ سے بھی کبھی MAC کاپی نہ کریں؛ وہ قدر استعمال کریں جو یہ کلائنٹ اس اکاؤنٹ کے لیے لاگ کرتا ہے، اور جس تاریخ کو آپ نے اسے تصدیق کیا اسے درج کریں۔
اسکرپٹ کو اتنا مختصر رکھیں کہ ایک نشست میں پڑھا جا سکے۔ لاگ تجزیہ کرنے والے ورک اراؤنڈ فطرتاً عارضی ہوتے ہیں۔ بچنے والے وہ ہیں جنہیں مستقبل کا قاری اصل دھاگے کے بغیر سمجھ سکے۔