OpenVPN 3 Linux: ফিরে যাওয়ার আগে D-Bus ত্রুটি পড়ুন
পাঁচটি পরিষেবা, একটি ফ্রন্টএন্ড। D-Bus ত্রুটিকে সেই উপাদানের সঙ্গে যুক্ত করুন যা অস্বীকার করেছে, সেশন আছে কি না দেখুন, তারপর সেই সীমায় সংশোধন করুন।
OpenVPN 3 Linux-এর ব্যর্থতাগুলো অপরিচিত নামসহ D-Bus পদ্ধতি ত্রুটি হিসেবে আসে, এবং প্রলোভন হলো প্যাকেজের সংস্করণ নিচে নামিয়ে আশা করা। ক্লায়েন্ট একটি প্রোগ্রাম নয়: কমান্ড-লাইন ফ্রন্টএন্ড বাসের মাধ্যমে সেই পরিষেবাগুলোর সঙ্গে কথা বলে যারা প্রোফাইল, সেশন, VPN ইঞ্জিন এবং বিশেষাধিকারপ্রাপ্ত নেটওয়ার্ক পরিবর্তনের মালিক। এই পাঁচটির মধ্যে কে ব্যর্থ কলের মালিক তা নির্ধারণ করাই রোগনির্ণয়ের বড় অংশ, এবং ফিরে যাওয়ার বদলে একটি কমান্ডের খরচ। এরপর সেই সিদ্ধান্তই, যে ক্রমে ব্যর্থতাগুলো সাধারণত দেখা দেয়।
একটি কমান্ডের পিছনে পাঁচ মালিক
পাঁচটি প্রক্রিয়া গুরুত্বপূর্ণ, এবং প্রত্যেকটির নিজস্ব বাস নাম আছে: যে ফ্রন্টএন্ড আপনার কমান্ড গ্রহণ করে, কনফিগারেশন ব্যবস্থাপক যা প্রোফাইল ও তাদের প্রবেশাধিকার নীতি রাখে, সেশন ব্যবস্থাপক যা সেশনের আয়ুর মালিক, ব্যাকএন্ড যা OpenVPN 3 Core Engine-এর মাধ্যমে সংযোগ চালায়, এবং নেটওয়ার্ক কনফিগারেশন পরিষেবা যা ইন্টারফেস, রুট ও DNS সেটিংস ইনস্টল করে। তাই কনফিগারেশন বস্তুর নাম নেওয়া ত্রুটি ব্যাকএন্ডের ত্রুটি নয়, এবং যে ব্যাকএন্ড শুরু হয় না তা প্রমাণীকরণের ব্যর্থতা নয়। বার্তাটিকে সেই সারিগুলোর একটিতে রাখা কোনো পরিবর্তনের আগেই ঘটতে হবে, কারণ প্রতিটি পরবর্তী ধাপ কোন সারি সত্য তার উপর নির্ভর করে। সারি অনুমান করা সেই পথ যেখানে একটি ছোট সংশোধন প্যাকেজ নিয়ে দুপুরভর কাজে পরিণত হয়।
অন্য কিছু জিজ্ঞাসা করার আগে সিস্টেম বাসকে জিজ্ঞাসা করুন কোন পরিষেবা উপস্থিত, তারপর নিশ্চিত করুন যে ইনস্টল করা অংশগুলো একটি সংস্করণে একমত। OpenVPN 3 Linux সেই পরিষেবাগুলোকে সিস্টেম ইউনিট হিসেবে নিবন্ধন করে, তাই জিজ্ঞাসা করার বাস হলো সিস্টেম বাস, সংস্করণের প্রশ্নে প্রশাসনিক ক্ষমতা লাগে, এবং --user দিয়ে তৈরি তালিকা আপনার লগইন সেশন পড়ে, যেখানে ইউনিটগুলো কখনো দেখা যায় না। পরিষেবাগুলো চাহিদামতো সক্রিয় হয় এবং কিছু নিষ্ক্রিয় থাকলে বন্ধ হয়ে যায়, তাই আপনার প্রথম অনুরোধের আগে অনুপস্থিত পরিষেবাকে এখনো কোনো কিছু জিজ্ঞাসা করা হয়নি। নিচের তিনটি কমান্ড VPN সেশন না খুলেই উপস্থিতি, সংস্করণ ও ইউনিটের অবস্থা জানায়।
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'প্রতিটি তালিকা আসলে কী প্রমাণ করে
ক্লায়েন্টের নিজের দৃশ্যগুলোই সবচেয়ে সস্তা প্রমাণ, এবং তাদের প্রত্যেকটি যতটা দেখা যায় তার চেয়ে কম প্রমাণ করে। কনফিগারেশন তালিকায় প্রোফাইল দেখায় যে একটি প্রোফাইল আমদানি হয়েছে এবং এ নিয়ে কিছুই বলে না যে কেউ এর সঙ্গে সংযুক্ত হতে পারে কি না। সেশন তালিকায় সেশন দেখায় যে সেশন বস্তু আছে এবং এ নিয়ে কিছুই বলে না যে দূরবর্তী প্রমাণীকরণ শেষ হয়েছে কি না।
openvpn3 configs-list
openvpn3 sessions-listসেই আউটপুটে বস্তুর পথগুলো বাসে ব্যবস্থাপিত বস্তু নির্দেশ করে, ফাইল নয়, তাই সেগুলো সম্পাদনা করা যায় না, এবং আগে লিপিবদ্ধ পথ সেই মুহূর্তেই পুরোনো হয়ে যায় যখন সেই সেশন বিচ্ছিন্ন হয়। আপনার নোটের একটি পুনরায় ব্যবহার করলে "no such object" ত্রুটি তৈরি হয় যার VPN-এর সঙ্গে কোনো সম্পর্ক নেই। নিচের ধাপ সারণি দেখায় সংযোগের প্রতিটি ধাপ কী প্রতিষ্ঠা করে এবং কী খোলা রাখে, আর ফিরে যাওয়ার সিদ্ধান্ত ঠিক এই পার্থক্যের উপর নির্ভর করে। আপনার প্রমাণের সঙ্গে মেলা সারি পড়ুন, তারপর ত্রুটির পাঠ আবার পড়ুন।
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
সংযোগ কল সুড়ঙ্গ থাকার আগেই ফিরে আসে
সংযোগ কল আপনাকে পর্যবেক্ষণের জন্য একটি সেশন দেয় এবং ফিরে আসে, তাই আপাত সফল কলের পরে নীরবতা একটি স্বাভাবিক মধ্যবর্তী অবস্থা, বিরোধ নয়। ফ্রন্টএন্ডকে তবুও অবস্থার পরিবর্তন অনুসরণ করতে হবে এবং প্রতিটি মিথস্ক্রিয়া অনুরোধের উত্তর দিতে হবে। যে প্রোফাইলের প্রমাণপত্র দরকার এবং উত্তর পায় না, তা এমন অবস্থায় অপেক্ষা করে যা দেখতে ঠিক আটকে যাওয়া ব্যাকএন্ডের মতো। সেই অপেক্ষার অবস্থাটি চেনা দরকার, কারণ এটি মানুষকে ভুল উপাদানের কাছে পাঠায়।
যখন কোনো প্রচেষ্টা চলছে, সেই প্রোফাইলের জন্য সেশন তালিকা এবং ফ্রন্টএন্ডের নিজের লগ দেখুন। যে সেশন তার শুরুর অবস্থা কখনো ছাড়ে না তা থেমে যাওয়া উপাদানের নাম নেয়, এবং লগ সাধারণত প্রথম কয়েকটি সারিতেই তার নাম নেয়। প্রোফাইলের নাম হাতের কাছে রাখুন, কারণ লগ কমান্ড সেশন পথ নয় বরং প্রোফাইল নেয়, যা পথ পুনরায় ব্যবহারের বদলে তালিকা আবার পড়ার আরেকটি কারণ।
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6সেশন না খুলেই একটি উপাদানের লগ পড়া
যখন ফ্রন্টএন্ড কিছু কাজের কথা বলে না, তখন নতুন সংযোগ শুরু করার বদলে যে উপাদান ব্যর্থতা লগ করেছে তার কাছে যান। কনফিগার করা systemd-journald লগার থাকলে প্রশাসকের সীমিত জার্নাল দৃশ্য একটি উপাদানের ঘটনা পড়ে, বাস নীতি স্পর্শ না করে এবং সেশন না খুলেই, এবং এটি গুরুত্বপূর্ণ কারণ যে রোগনির্ণয় মাপা হচ্ছে সেই সিস্টেমকেই বদলে দেয় তা খুব কম প্রমাণ করে। ইউনিট অনুযায়ী ছাঁকুন, syslog ট্যাগ অনুযায়ী নয়: আলাদা পরিষেবা ইউনিট সাধারণ শনাক্তকরণের নিশ্চয়তা দেয় না, তাই ট্যাগের প্রশ্নে খালি পাতা ফিরে আসতে পারে অথচ ইউনিট নিজেই ব্যর্থতা লিপিবদ্ধ করেছে।
কাউকে সাহায্য চাওয়ার আগে চারটি ক্ষেত্র লিখুন: ত্রুটির পূর্ণ নাম, সংশ্লিষ্ট পরিষেবা ও বস্তু, সময়ের ছাপ, এবং ইনস্টল করা প্যাকেজের সংস্করণ। এগুলোই একজন রক্ষণাবেক্ষণকারীর দরকার, এবং এর কোনো একটির জন্যও প্রোফাইল বা প্রমাণপত্র টিকিটে আটকাতে হয় না। ত্রুটি চুপ করাতে বাস প্রবেশাধিকার নীতি প্রশস্ত করা রোগনির্ণয় নয়, এটি সেই সীমা মুছে দেয় যা আপনার পক্ষে উপাদানের নাম বলছিল। প্রোফাইলের গোপন সামগ্রী ভাগ করা প্রতিবেদন থেকে বাইরে থাকে, যে কারণে প্রমাণপত্র বাইরে থাকে সেই একই কারণে।
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>যে সীমা অস্বীকার করেছিল তার সংশোধন
মানচিত্রের প্রতিটি সারির নিজস্ব সংশোধন আছে, এবং সারিগুলো একে অপরের জায়গা নেয় না। প্রোফাইলে প্রত্যাখ্যাত কাজ নীতি ও মালিকানার প্রশ্ন, আর সক্রিয় না হওয়া ব্যাকএন্ড পরিষেবা ও প্যাকেজিংয়ের প্রশ্ন। প্রমাণীকরণ প্রত্যাখ্যানকারী সার্ভার এর কোনোটিই নয়, তাই বারবার পাসওয়ার্ড বদলে স্থানীয় সক্রিয়করণের সমস্যা সারানো যায় না। ভুল সংশোধন বাছাই সেই পথ যেখানে নীতির সমস্যা পুনরায় ইনস্টলে পরিণত হয়।
প্যাকেজ পরিবর্তনের পরে পুরোনো বাইনারি তার জায়গায় কপি না করে একটি সুসংগত ও সমর্থিত ইনস্টল যাচাই করুন। নিয়ন্ত্রিত ফিরে যাওয়া প্রমাণিত রিগ্রেশনের বৈধ উত্তর, শর্ত থাকে যে প্যাকেজগুলো সামঞ্জস্যপূর্ণ থাকে এবং সমর্থিত রক্ষণাবেক্ষণের দিকে ফেরার পথ থাকে। সেই পথটি পরিষেবা চালু হওয়া বন্ধ করার আগেই প্রতিষ্ঠা করুন, পরে নয়।
অন্য প্ল্যাটফর্ম একই মূল VPN লাইব্রেরি ভাগ করতে পারে Linux-এর বাস পরিষেবা না ভাগ করেই, তাই Windows-এ একইরকম ব্যর্থতা এই সম্পর্কে কিছু বলে না। D-Bus-এর সংক্ষিপ্ত বিবরণ কনফিগারেশন ও সেশনের জন্য উন্মুক্ত বস্তুর পথগুলো নথিভুক্ত করে, এবং এই রোগনির্ণয় যে স্থাপত্যের উপর দাঁড়িয়ে আছে তা ঠিক সেই অংশ। একবার পড়ুন, এবং পরের ত্রুটিটি এমন উপাদানসহ আসবে যা আগেই তার সঙ্গে যুক্ত।