میں نے GNOME ترتیبات میں فائل سے درآمد… منتخب کیا، ایسا پروفائل چنا جو وینڈر کے کلائنٹ کے ساتھ کام کرتا ہے، اور ڈائیلاگ فہرست میں کچھ شامل کیے بغیر بند ہو گیا۔ دوسرے لیپ ٹاپ پر درآمد مکمل ہوئی، کنکشن پروفائل کے نام سے ظاہر ہوا، اور پھر پہلی تصدیق کی درخواست پر ناکام ہو گیا۔ NetworkManager آپ کی .ovpn یا wg-quick فائل کو کبھی ویسے ہی نہیں چلاتا۔ وہ فائل تجزیہ کار کو دیتا ہے، تجزیہ کار اسے NetworkManager کے اپنے کنکشن فارمیٹ میں بدلتا ہے، اور اس کے بعد سرنگ اسی تجزیہ شدہ شے سے بنتی ہے — راز، روٹس، DNS اور باقی سب کچھ۔ پس مفید سوال یہ نہیں کہ فائل کیوں خراب ہے، بلکہ یہ کہ تجزیہ ہوا یا نہیں اور اس نے کیا محفوظ رکھا۔

درآمد فائل کے ساتھ درحقیقت کیا کرتی ہے

OpenVPN کے لیے تجزیہ کار پلگ ان پیکج میں رہتا ہے، اور جو کنکشن وہ بناتا ہے وہ org.freedesktop.NetworkManager.openvpn جیسی D-Bus سروس کی طرف اشارہ کرتا ہے۔ پلگ ان نہیں تو تجزیہ کار نہیں: قسم nmcli کے لیے نامعلوم ہے، اور VPN شامل کرنے کی گرافیکل فہرست شاید درآمد کا کوئی اندراج ہی نہ دکھائے۔ WireGuard ایک اہم نکتے میں مختلف ہے — NetworkManager کے پاس 1.30 سیریز سے اپنی WireGuard ترتیبات ہیں، اس لیے الگ پلگ ان پیکج نہیں، مگر wg-quick پڑھنے والا صرف ان بلڈز میں موجود ہے جو اسے فراہم کرتے ہیں۔

بہرحال فائل ایک بار پڑھی جاتی ہے۔ نتیجہ /etc/NetworkManager/system-connections/ کے تحت keyfile کے طور پر لکھا جاتا ہے، کنکشن کے نام پر، root کی ملکیت میں اور دوسرے صارفین کے لیے ناقابلِ قرأت کیونکہ اس میں کلیدی مواد ہے۔ یہ keyfile اب کنکشن ہے؛ اصل .ovpn کو بعد میں ترمیم کرنا کچھ نہیں بدلتا۔

تین علامات تین مختلف مراحل سے تعلق رکھتی ہیں۔ درآمد کا اندراج نہ ہونا یا نامعلوم قسم کا مطلب ہے کہ پلگ ان یا ورژن موجود نہیں۔ کسی ہدایت کا نام لینے والی درآمدی خرابی کا مطلب ہے کہ تجزیہ کار نے فائل پڑھی اور اس کا کچھ حصہ مسترد کیا۔ ایسا کنکشن جو موجود ہو مگر کبھی فعال نہ ہو، اس کا مطلب ہے کہ تجزیہ شدہ شے نامکمل ہے یا سرور اسے مسترد کر رہا ہے۔ کچھ بھی ترمیم کرنے سے پہلے طے کریں کہ آپ کے پاس تین میں سے کون سی صورت ہے۔

پروفائل کی خرابی دور کرنے سے پہلے پلگ ان کی تصدیق کریں

غائب پلگ ان بالکل خراب پروفائل جیسا دکھتا ہے، اس لیے پہلے پیکج چیک کریں۔ Debian اور Ubuntu پر OpenVPN معاونت network-manager-openvpn کے ساتھ ایک ڈیسک ٹاپ مددگار کے طور پر آتی ہے؛ Fedora پر پیکجز NetworkManager-openvpn اور NetworkManager-openvpn-gnome ہیں؛ Arch پر یہ networkmanager-openvpn ہے۔

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

پھر مطلق راستے سے درآمد کریں: nmcli connection import type openvpn file /home/you/profile.ovpn۔ نسبتی راستے عام طور پر کام کرتے ہیں، مگر ایسی شیل جس نے ڈائریکٹری بدلی ہو، تیز درآمد کو چکر میں بدل دیتی ہے۔ WireGuard کے لیے nmcli --version چیک کریں اور یقینی بنائیں کہ کرنل کا حصہ modprobe wireguard کے ساتھ موجود ہے؛ ایسی درآمد جو ماڈیول کے بغیر مشین پر کامیاب ہو، آپ کو ایسے کنکشن کے ساتھ چھوڑ دیتی ہے جس کا آلہ کبھی ظاہر نہیں ہوتا۔ nmcli حوالہ import ذیلی کمانڈ اور قبول شدہ قسم کے ناموں کی دستاویز کرتا ہے۔ اگر type wireguard یکسر مسترد ہو جائے تو بلڈ اس خصوصیت سے پرانا ہے، اور درست قدم ڈسٹری بیوشن پیکج یا backport ہے — کنفیگریشن کو کسی بھی ڈائریکٹری میں نقل کر کے یہ امید کرنا نہیں کہ کوئی اسے پڑھے گا۔

OpenVPN کنکشن پڑھیں، .ovpn نہیں

جب کنکشن موجود ہو تو فائل دوبارہ پڑھنے کے بجائے تجزیہ شدہ ترتیبات پڑھیں: nmcli connection show "Work VPN" | grep -E '^vpn\.'۔ آپ کو remote اور پورٹ، ٹرانسپورٹ، شناختی مواد — ca، cert، key، tls-auth یا tls-crypt — اور تصدیق کا طریقہ چاہیے۔ نجی کلید کے پاس ورڈ والے پروفائل میں sudo nmcli --show-secrets connection show "Work VPN" شامل کریں اور secret جھنڈے دیکھیں: 0 none ہے، یعنی راز keyfile میں ہے؛ 1 agent-owned ہے؛ 2 not-saved ہے، یعنی یہ کبھی keyfile میں نہیں لکھا جاتا؛ 4 not-required ہے، یعنی کوئی راز درکار ہی نہیں۔ یہ بٹس ہیں، پیمانہ نہیں، اس لیے 3 محض agent-owned جمع not-saved ہے۔ ایسا راز جو ہر سیشن میں ایک بار پوچھا جائے، agent-owned (1) ہے جہاں ایجنٹ اسے طلب کرتا ہے؛ اس کے لیے الگ جھنڈا نمبر نہیں۔ جھنڈوں کا اختلاف عام وجہ ہے کہ پروفائل ڈیسک ٹاپ ایپلیٹ سے جڑتا ہے اور اسکرپٹ یا بوٹ پر ناکام ہوتا ہے۔

یہ دیکھنے کا تیز ترین طریقہ کہ تجزیہ کار نے کیا گرا دیا، پلگ ان سے فائل واپس لکھنے کی درخواست کرنا اور پھر اس کا موازنہ کرنا ہے: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn۔ وہ ہدایات جو اس فرق میں غائب ہو جائیں وہ کنکشن کے وقت موجود نہیں ہوں گی۔ ہکس عام مشتبہ ہیں — script-security، up، down اور route-up ایسے اسکرپٹ کی توقع کرتے ہیں جو بلند اختیارات سے چلے اور جان بوجھ کر منتقل نہیں کیے جاتے۔ تصدیق کم نہ کریں اور درآمد کامیاب کرنے کے لیے اضافی اختیارات نہ دیں؛ غیر معاون آپشن عام طور پر پلگ ان کی خصوصیات کا مجموعہ ظاہر کرتا ہے نہ کہ ناقابلِ رسائی سرور۔ یہ رویہ NetworkManager ڈسپیچر اسکرپٹ یا سرور کی طرف کی پالیسی میں منتقل کریں۔

یہ بھی تصدیق کریں کہ شناختی میدان بچ گئے: CA حوالہ، remote-cert-tls اور کوئی بھی نام کی جانچ جس پر پروفائل انحصار کرتا تھا۔ وہ کنکشن جو ان کے بغیر اوپر آئے وہ شاید اسی پتے پر جواب دینے والے کسی بھی چیز سے بات کر رہا ہو۔

WireGuard کنکشن پڑھیں، wg-quick فائل نہیں

wg-quick فائل شیل معنویت والا فارمیٹ ہے؛ درآمد شدہ کنکشن ترتیبات کا مجموعہ ہے۔ PrivateKey انٹرفیس کی نجی کلید بن جاتا ہے، Address ایک یا زیادہ IPv4 اور IPv6 پتے بن جاتے ہیں، DNS NetworkManager کی resolver خصوصیات پر نقش ہوتا ہے، MTU wireguard.mtu پر نقش ہوتا ہے (wg-quick کی اپنی طے شدہ قدر 1420 ہے)، اور ہر peer بلاک ایک peer اندراج بن جاتا ہے جس میں عوامی کلید، endpoint، اجازت شدہ IPs اور persistent keepalive ہوتے ہیں۔ جو محفوظ ہوا اسے nmcli --show-secrets connection show wg0 سے چھاپیں؛ اگر peer فہرست اس آؤٹ پٹ میں نظر نہ آئے تو keyfile پڑھیں:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

جو نہیں بچتا وہ wg-quick کا شیل والا نصف ہے۔ PreUp، PostUp، PreDown، PostDown اور Table اس آلے کا رویہ ہیں، WireGuard انٹرفیس کی خصوصیات نہیں، اس لیے درآمد کے بعد انہیں کوئی نہیں چلاتا۔ اگر اصل نے Table = off استعمال کیا تاکہ طے شدہ روٹ کو چھیڑا نہ جائے، تو نئے NetworkManager ریلیز اسی مقصد کے لیے ip4-auto-default-route اور ip6-auto-default-route پیش کرتے ہیں؛ انہیں واضح طور پر مقرر کریں بجائے یہ فرض کرنے کے کہ کنکشن اسکرپٹ کی طرح برتاؤ کرتا ہے۔ ایسا ہک جو حسبِ ضرورت روٹ دھکیلتا تھا، اسے کنکشن کی روٹنگ ترتیبات میں وہ روٹ درکار ہے، ورنہ وہ محض غائب ہو گا۔

کنکشن کو بالکل ایک مالک دیں

کلاسیکی بعد کی خرابی وہ کنکشن ہے جو اگلے بوٹ تک کام کرتا ہے اور پھر لوپ میں پڑ جاتا ہے۔ عام طور پر [email protected] پچھلے تجربے سے اب بھی فعال تھا، یا وینڈر کلائنٹ اپنا ڈیمن چلا رہا تھا، اور دو مالک ایک ہی منزل کے لیے روٹس اور DNS لکھ رہے تھے۔ NetworkManager resolver اپنے راستے سے مقرر کرتا ہے، wg-quick resolvconf کے ذریعے لکھتا ہے، اور آخری لکھنے والا جیتتا ہے — اس لیے نام کی تحلیل کام کرتی ہے، پھر رک جاتی ہے، پھر دوبارہ کام کرتی ہے۔ systemctl status wg-quick@wg0، nmcli connection show --active اور ip link show type wireguard چیک کریں، پھر دوسرے مالک کو غیر فعال کریں بجائے اس کی metric ایڈجسٹ کرنے کے۔

اگر آپ کو واقعی دونوں درکار ہوں تو انہیں الگ انٹرفیس اور غیر متداخل اجازت شدہ IPs دیں، اور بالکل ایک کو طے شدہ روٹ نصب کرنے دیں۔ مختلف metrics والے دو طے شدہ روٹس split tunnel نہیں؛ یہ ایک دوڑ ہے جس کا فیصلہ وہ سروس کرتی ہے جو دوسری شروع ہو۔ اور دوبارہ جڑنے کے بعد لاگو حالت دوبارہ دیکھیں — resolver کی ایک بار کی دستی ترمیم جو سب کچھ چلا دے، درآمد کے مکمل ہونے کا ثبوت نہیں۔

ٹریفک سے تصدیق کریں اور دوبارہ آغاز سے گزریں

کنکشن کو nmcli connection up "Work VPN" سے اوپر لائیں، پھر آئیکن پر بھروسا کرنے کے بجائے حالت، پتہ اور روٹس پڑھیں: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE'، ip route show default اور ایسے نام کی حقیقی استفسار جو صرف سرنگ کے اندر حل ہو۔ handshake یا کامیاب ping صرف یہ ثابت کرتا ہے کہ خفیہ کاری کام کرتی ہے؛ یہ فارورڈنگ، split tunnel سابقوں یا نجی DNS کے بارے میں کچھ نہیں کہتا، اور عام طور پر یہی حصے ٹوٹتے ہیں۔

پھر دوبارہ شروع کریں اور دہرائیں۔ autoconnect رویہ، تبدیل شدہ نام والا انٹرفیس اور ایسا پلگ ان جو آلے کے بعد لوڈ ہو، یہ سب وہ خرابیاں ہیں جو آپ صرف صاف بوٹ پر دیکھتے ہیں۔ journalctl -u NetworkManager -b --no-pager | tail -n 40 دکھاتا ہے کہ ڈیمن نے اس بوٹ میں اس کنکشن کے ساتھ کیا کیا۔ دوسرے کمپیوٹر کے لیے keyfile کاپی کریں اور اسے root کی ملکیت میں 600 موڈ کے ساتھ رکھیں، یا OpenVPN کے لیے nmcli connection export استعمال کریں اور نتیجے میں بننے والی .ovpn دوبارہ درآمد کریں — برآمدگی راستے کا WireGuard میں کوئی متبادل نہیں، اس لیے وہ سمت فائل کی نقل یا محفوظ اصل سے نئی درآمد ہے۔

مختصر نسخہ، ترتیب سے: پلگ ان یا NetworkManager ورژن کی تصدیق کریں، مطلق راستے سے درآمد کریں، secret جھنڈوں سمیت تجزیہ شدہ ترتیبات پڑھیں، OpenVPN برآمدگی کا اصل سے موازنہ کریں، WireGuard کی طرف ہکس اور روٹس چیک کریں، کوئی بھی دوسرا مالک غیر فعال کریں، اور پھر دوبارہ آغاز کے بعد نام کی تحلیل اور روٹ ٹیبل کی تصدیق کریں۔ جب کوئی کنکشن یہ سب پاس کر لے تو وہ پروفائل فائل جس نے اسے شروع کیا محفوظ ذخیرے میں واپس جا سکتی ہے۔

متعلقہ مضامین