Windows میں VPN انسٹال ہے، Linux بوٹ میں نیٹ ورک نہیں: کیا جانچیں
ہر بوٹ اپنا نیٹ ورک اسٹیک چلاتا ہے، اس لیے Windows کا VPN فلٹر Linux میں فعال نہیں ہوتا۔ کچھ بھی ری سیٹ کرنے سے پہلے لنک، پتہ، راستہ اور DNS جانچیں۔
آپ Windows میں VPN انسٹال کرتے ہیں، Linux میں دوبارہ بوٹ کرتے ہیں، اور تار والا کنکشن مردہ ہے۔ واضح کہانی خود لکھی جاتی ہے: VPN نے کچھ پیچھے چھوڑا۔ کہانی غلط ہے، کیونکہ دونوں بوٹ الگ کرنل، الگ ڈرائیور، الگ روٹنگ ٹیبل اور الگ حل کنندہ چلاتے ہیں۔ Windows کا نیٹ ورک فلٹر Linux کے اندر نہیں چلتا، اس لیے خرابی Linux اسٹیک میں ہے یا اس چیز میں جو دونوں بوٹ واقعی شیئر کرتے ہیں، جیسے ہارڈویئر، فرم ویئر یا راؤٹر۔
علامت اور غلط نتیجہ
مشاہدے کا مفید حصہ وقت ہے: تبدیلی کے بعد خرابی ظاہر ہوئی۔ غیر مفید حصہ Windows VPN کی طرف سببی چھلانگ ہے، جو دوسرے آپریٹنگ سسٹم میں نہیں چل سکتا۔ دونوں کو الگ کرنا ہی پورا کام ہے۔ کیبل چھونے سے پہلے ٹائم لائن لکھیں۔
دونوں بوٹ جو واقعی شیئر کرتے ہیں وہ فزیکل اڈاپٹر، کیبل، سوئچ پورٹ اور اوپر کا سب کچھ ہے۔ یہ حقیقی مشترکہ متغیرات ہیں، اور Linux اسٹیک جانچنے کے بعد ان کی جانچ بنتی ہے۔
چار کمانڈوں میں Linux اسٹیک کا اسنیپ شاٹ لیں
کچھ بدلنے سے پہلے صرف پڑھنے کی حالت میں شروع کریں اور حالت درج کریں: انٹرفیس کی موجودگی کے لیے ip -br link، پتوں کے لیے ip -br address، IPv4 راستوں کے لیے ip route اور جہاں IPv6 اہم ہے وہاں ip -6 route۔ ip ٹول کا حوالہ ان اشیاء کو الگ کرتا ہے، اور فہرست میں انٹرفیس دکھنا اس بات کا ثبوت نہیں کہ اس کا کام کرنے والا پتہ یا قابل استعمال راستہ ہے۔
آؤٹ پٹ کو فائل میں محفوظ کریں تاکہ بعد میں کام کرنے والے بوٹ سے موازنہ کر سکیں۔ جو اسنیپ شاٹ آپ دوبارہ نہیں بنا سکتے وہ صرف حالت کی یاد ہے۔
یہ لنک ہے، پتہ، راستہ یا نام؟
چار مختلف خرابیاں براؤزر سے ایک جیسی دکھتی ہیں۔ ڈیوائس بالکل غائب ہو سکتی ہے، کیرئیر کے بغیر موجود ہو سکتی ہے، جڑی ہو مگر متوقع پتے کے بغیر، یا پتہ ہو مگر منزل تک راستہ نہ ہو۔ کچے پتے چلتے ہوئے نام کی تحلیل کا ناکام ہونا پانچواں کیس ہے، اور یہ ڈرائیور کا نہیں، حل کنندہ کا ہے۔
ہر کیس مختلف کام کی طرف اشارہ کرتا ہے: غائب ڈیوائس کے لیے ڈرائیور یا فرم ویئر، کیرئیر نہ ہونے پر کیبلنگ یا سوئچ، پتہ نہ ہونے پر DHCP یا مستقل ترتیب، اور راستہ نہ ہونے پر روٹنگ یا پالیسی۔ حل کنندہ کا مسئلہ systemd-resolved، NetworkManager یا مقامی DNS ترتیب کی طرف اشارہ کرتا ہے۔
جانچیں کہ Linux انسٹالیشن کا اپنا VPN یا مستقل فائر وال ترتیب ہے یا نہیں۔ مقامی ٹنل یا nftables قواعد کا مجموعہ Linux طرف کا سبب ہے، اور نہ چلنے والے Windows پروگرام سے زیادہ امکان کے ساتھ خرابی کی وضاحت کرتا ہے۔
پھر بوٹ کی منتقلی کا موازنہ کریں
Windows Fast Startup ایک ہائبرڈ شٹ ڈاؤن ہے جو مکمل بوٹ کے بجائے کرنل سیشن کی حالت رکھتا ہے۔ Microsoft کی پاور اسٹیٹ دستاویز اسے ری اسٹارٹ اور مکمل شٹ ڈاؤن سے الگ کرتی ہے، اسی لیے وہی ہارڈویئر دونوں منتقلیوں میں مختلف برتاؤ کر سکتا ہے۔
اگر خرابی ایک آپریٹنگ سسٹم سے دوسرے کی طرف جانے پر منحصر ہے تو کام محفوظ کرنے کے بعد دستاویزی ری اسٹارٹ یا مکمل شٹ ڈاؤن کا عام راستے سے موازنہ کریں۔ منتقلی کی پیروی کرنے والا نتیجہ ڈرائیور، ڈیوائس یا فرم ویئر کی حالت جانچنے کا جواز دیتا ہے، اور بذات خود یہ ثابت نہیں کرتا کہ Fast Startup نے کوئی خاص اڈاپٹر خرابی پیدا کی۔
درج کریں کہ کس آپریٹنگ سسٹم نے آخری بار اڈاپٹر استعمال کیا، منتقلی کی قسم، Linux میں لنک کی حالت اور پہلی ناکام کارروائی۔ کون سا اسٹیک ٹوٹا یہ جانے بغیر دونوں انسٹالیشنوں سے VPN سافٹ ویئر ہٹانے سے کہیں زیادہ قیمتی ہے ٹھنڈے بوٹ اور گرم منتقلی کا دہرایا جا سکنے والا فرق۔
کیا نہ بدلیں
پہلے قدم کے طور پر دونوں نیٹ ورک اسٹیک ری سیٹ نہ کریں۔ یہ موازنہ تباہ کرتا ہے اور اکثر کچھ ٹھیک نہیں کرتا، کیونکہ اصل سبب کبھی شناخت نہیں ہوا۔ Linux ٹھیک کرنے کے لیے Windows VPN دوبارہ انسٹال نہ کریں، اور بوٹ منتقلی خرابی سے متعلق تھی اس لیے فرم ویئر سیٹنگز بے ترتیب نہ بدلیں۔
ip ٹول کا حوالہ اوپر استعمال شدہ لنک، پتہ اور راستہ اشیاء کی دستاویز کرتا ہے۔ پہلے Linux طرف پڑھیں، اسنیپ شاٹ رکھیں، اور پھر ہی فیصلہ کریں کہ مشترکہ ہارڈویئر پرت جانچنے کے قابل ہے یا نہیں۔