NetworkManager-এ OpenVPN ও WireGuard ফাইলে আমদানি ব্যর্থ হয়

আমি 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 ব্লক public key, endpoint, অনুমোদিত IP ও persistent keepalive সহ peer এন্ট্রি হয়। যা সংরক্ষিত হয়েছে 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 টিউন করার বদলে।

যদি সত্যিই দুটোই দরকার হয়, তাদের আলাদা ইন্টারফেস ও অসম্পর্কিত অনুমোদিত IP দিন, এবং ঠিক একটি ডিফল্ট রুট ইনস্টল করতে দিন। ভিন্ন 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 পক্ষে হুক ও রুট পরীক্ষা করুন, যেকোনো দ্বিতীয় মালিক নিষ্ক্রিয় করুন, এবং তারপর রিবুটের পর নাম বিশ্লেষণ ও রুট টেবিল যাচাই করুন। যখন একটি সংযোগ এসব পাস করে, তখন যে প্রোফাইল ফাইল এটি শুরু করেছিল তা সুরক্ষিত ভাণ্ডারে ফিরে যেতে পারে।