Keyfile নাকি Netplan: VPN প্রোফাইল আসলে কোথায় সংরক্ষিত থাকে?
সংরক্ষিত VPN একটি keyfile-এ বা তৈরি করা Netplan ফাইলে থাকতে পারে। পুনরায় লেখা হয় এমন কিছু সম্পাদনার আগে সংযোগের UUID-কে তার আসল মালিকের সঙ্গে মিলিয়ে নিন।
আপনি যে ফাইলটি আমদানি করেছেন তা খুঁজে পাওয়া সহজ অংশ এবং প্রায়শই ভুল শুরু। আসল বিষয় হলো NetworkManager আজ কোন ফাইলকে সংরক্ষিত সংযোগ হিসেবে পড়ে, আর তা নির্ভর করে একটি সংযোগ শনাক্তকারী এবং ইনস্টল করা প্যাকেজগুলি যে কনফিগারেশন ব্যাকএন্ড সত্যিই ব্যবহার করে তার উপর। ওই প্রশ্নের উত্তর দেওয়ার আগেই আমদানি সম্পাদনা করা মানে একটি কার্যকর VPN-কে দুইটি আধা-সঠিক কনফিগারেশনে পরিণত করা।
আমদানি করা ফাইলটি সংরক্ষিত প্রোফাইল নয়
প্রতিটি VPN সমস্যার চারপাশে তিনটি নাম ঘোরে: সংযোগের নাম, আপনি যে ফাইলটি আমদানি করেছেন তার নাম, এবং টানেল উঠলে যে ভার্চুয়াল ইন্টারফেস দেখা যায়। এর কোনোটিই সংরক্ষিত কনফিগারেশন শনাক্ত করে না, আর সংযোগের নাম সম্পাদনা করা যায় যদিও তার পিছনের ফাইল নিজের মূল শনাক্তকারী ধরে রাখে।
শুধু-পাঠের একটি তালিকা দিয়ে শুরু করুন এবং লেবেলের বদলে শনাক্তকারী দিয়ে উদ্দিষ্ট VPN বেছে নিন:
nmcli -f NAME,UUID,TYPE connection showটিকিটে পেস্ট করা যেকোনো তালিকা থেকে এন্ডপয়েন্ট হোস্টনেম ও পরিচয় লেবেল বাদ রাখুন। কাজের অংশ হলো টাইপ ও শনাক্তকারী; বাকিটা এমন প্রসঙ্গ যা অপরিচিত কারও দরকার নেই। শেয়ার করার আগে বাকিটা আড়াল করুন এবং বলুন যে আপনি তা করেছেন, যাতে কেউ না ভাবে ফাঁকাগুলোর মানে কী।
keyfile-এর অবস্থান একই অর্থ বোঝায় না
নেটিভ keyfile প্লাগইনে সংযোগ ফাইল তিনটি ডিরেক্টরিতে দেখা যেতে পারে, আর তাদের মধ্যে পার্থক্য সুবিধা নয়, স্থায়িত্ব।
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
রানটাইম কপি সম্পাদনা পরের শুরু পর্যন্ত সফল মনে হয়, তখন পরিবর্তনটি বাষ্পীভূত হয় এবং ফাইলটি রহস্যজনকভাবে ফিরিয়ে দেওয়া দেখায়। প্যাকেজ-প্রদত্ত কপি সম্পাদনা কাজ করে যতক্ষণ না একটি আপগ্রেড তা প্রতিস্থাপন করে, যা একই শিক্ষার আরও ধীর ও বিভ্রান্তিকর সংস্করণ।
keyfile ডকুমেন্টেশন একটি সম্মানযোগ্য বিবরণ যোগ করে: ওই ফাইলগুলিতে ব্যক্তিগত কী ও পাসফ্রেজ থাকতে পারে, এবং root ছাড়া অন্য ব্যবহারকারীরা পড়তে বা লিখতে পারে এমন যেকোনো keyfile NetworkManager উপেক্ষা করে। একটি সেটিং খুঁজতে ডিরেক্টরির অনুমতি বাড়ানো সেই লোডিং আচরণই ভেঙে দেয় যা আপনি পরীক্ষা করতে চেয়েছিলেন।
যখন Netplan স্থায়িত্বের মালিক
Ubuntu-তে Netplan-এর ডকুমেন্টেশনে বর্ণিত NetworkManager ইন্টিগ্রেশন, যা 23.10 থেকে পাওয়া যায়, স্থায়ী কপির জায়গা বদলে দেয়। অস্থায়ী নয় এমন সংযোগের জন্য এটি লেখে /etc/netplan/90-NM-<connection UUID>.yaml এবং এর অধীনে একটি ক্ষণস্থায়ী NetworkManager প্রোফাইল তৈরি করে /run/NetworkManager/system-connections/।
এটি একটি ডিস্ট্রিবিউশন ইন্টিগ্রেশন, প্রতিটি NetworkManager ইনস্টলেশনের নিয়ম নয়। YAML ফাইল খুঁজতে যাওয়ার আগে নিশ্চিত করুন যে ইনস্টল করা প্যাকেজগুলি সত্যিই এটি ব্যবহার করে। এটাও মনে রাখুন যে রানটাইম প্রোফাইল সম্পাদনার যোগ্য উৎসের বদলে অন্য কিছুর তৈরি করা উপস্থাপনা হতে পারে। দুটি কমান্ডের যাচাই ভুল ফাইল সম্পাদনার এক ঘণ্টা বাঁচায়।
ডকুমেন্টেড উদাহরণটি NetworkManager পাসথ্রু ডেটাসহ Netplan nm-devices টাইপের মাধ্যমে একটি OpenVPN সংযোগ সংরক্ষণ করে। Netplan-এর কোনো নির্দিষ্ট VPN ফিল্ডের নিজস্ব ব্যাখ্যা না থাকার অর্থ আপনার সংরক্ষিত VPN হারিয়ে যায়নি; এর অর্থ ফিল্ডটি অস্বচ্ছ ডেটা হিসেবে ভ্রমণ করে।
ক্ষণস্থায়ী ইন্টারফেস প্রোফাইল নয়
অ্যাক্টিভেশন এমন অস্থায়ী ভার্চুয়াল সংযোগ ও ইন্টারফেস তৈরি করে যা কখনো স্থায়ী হওয়ার কথা ছিল না। ইন্টিগ্রেশন ইচ্ছাকৃতভাবে প্রতিটির জন্য নতুন YAML ফাইল লেখে না, তাই /etc/netplan-এ তাদের অনুপস্থিতি প্যারেন্ট প্রোফাইল সংরক্ষিত আছে কি না সে সম্পর্কে কিছুই বলে না।
যদি আপনি এমন ফাইল খুঁজছেন যা আসে ও মিলিয়ে যায়, আপনি সম্ভবত আপনার কনফিগারেশনের বদলে এগুলোর একটি দেখছেন। এর বিষয়বস্তু থেকে কোনো সিদ্ধান্তে আসার আগে দেখুন এটি পুনরায় চালু হলে টিকে থাকে কি না। রিবুটে মিলিয়ে যাওয়া একটি রানটাইম ফাইল আপনাকে বলে এটি কখনো উৎস ছিল না, আর ওই একক পর্যবেক্ষণ পুরো তদন্তের দিক বদলে দেয়। এটি এটাও ব্যাখ্যা করে কেন সম্পাদনাটি তখন সফল মনে হয়েছিল।
গোপন তথ্য ও মালিকানা
একটি প্রোফাইল সম্পূর্ণ অন্য জায়গায় সংরক্ষিত সার্টিফিকেট বা কী-তে উল্লেখ করতে পারে, আর পাসওয়ার্ড NetworkManager-এর হতে পারে, ব্যবহারকারী-সেশন গোপন এজেন্ট দ্বারা সরবরাহ হতে পারে, বা ইচ্ছাকৃতভাবে সংরক্ষণ না করা হতে পারে। তাই একটি ফাইল খুঁজে পাওয়া অনিবার্য সূচনার জন্য কী দরকার সে সম্পর্কে খুব কমই ঠিক করে।
গোপন মান না ছাপিয়ে রেফারেন্স ও গোপন-ফ্ল্যাগ পরীক্ষা করুন। ডেস্কটপ লগইন এমন একটি এজেন্ট উপলব্ধ করতে পারে যা বুটের সময় ছিল না, আর তৈরি করা রানটাইম ফাইল কপি করলে সেই এজেন্ট পুনরুৎপাদিত হয় না। বাস্তব উপসর্গ হলো এমন টানেল যা কেউ লগইন করলে সংযোগ করে আর মেশিন একা চালু হলে ব্যর্থ হয়। এই ধরনটি রাউটিং নয়, গোপন তথ্যের মালিকানার দিকে ইঙ্গিত করে।
অনুমোদিত পরিবর্তনগুলি সংযোগের মালিক ম্যানেজারের মাধ্যমে করুন, তারপর সংরক্ষিত শনাক্তকারী ও কার্যকর সংযোগ দুটোই যাচাই করুন। একজন স্থায়ী মালিক রাখুন, কারণ আমদানি, তৈরি করা keyfile ও YAML উৎস আলাদাভাবে সম্পাদনা করলে পরের পুনঃসংযোগ কী ব্যবহার করবে তা নিয়ে তিনটি প্রতিদ্বন্দ্বী ব্যাখ্যা থেকে যায়। যা সত্যিই টিকে থাকে তা বেছে নিন, কেবল তা-ই সম্পাদনা করুন, এবং টিকিটে নোট করুন কোন ফাইলকে আপনি প্রামাণিক ধরেছেন। পরের ব্যক্তি এক লাইন উৎসের জন্য আপনাকে ধন্যবাদ দেবেন।