নেটওয়ার্ক ইন্টারফেসের নাম বদলের পরে Access Server তার বাইন্ডিং হারিয়েছে: কী ঠিক করুন

আপনি একটি নেটওয়ার্ক ইন্টারফেসের নাম বদলেছেন, বা এমন একটি মেশিন পুনরুদ্ধার করেছেন যার অ্যাডাপ্টার ভিন্ন নামে ফিরে এসেছে, আর এখন OpenVPN Access Server ডেমন চালু হয় না। ওয়েব ইন্টারফেস হয়তো সাড়া দিতে পারে, নাও পারে; কোন উপাদান পুরোনো নামের সঙ্গে বাঁধা ছিল তার উপর নির্ভর করে। সেবাটি নষ্ট হয়নি, কনফিগারেশন হারায়নি; একটি সেটিং এখনও এমন ইন্টারফেসের দিকে ইঙ্গিত করে যা হোস্টের আর নেই।

সাধারণ প্রতিক্রিয়া হলো ত্রুটি না যাওয়া পর্যন্ত পুনরায় ইনস্টল, পুনরায় আরম্ভ বা ডেটাবেস সম্পাদনা করা। প্রত্যেকটি ত্রুটির চেয়ে বড় পরিবর্তন, আর শেষটি সেই ব্যবহারকারী, অনুমতি ও নির্ভরতাগুলো মুছে দিতে পারে যেগুলো সার্ভারটিকে উদ্ধারের যোগ্য করেছিল। এটি একটি বাইন্ডিং সমস্যা, এবং এর একটি নির্দিষ্ট সমাধান আছে।

লক্ষণটি আসলে কী বলে

বাঁধতে না পারা ডেমন সাধারণত নিজের লগে বলে: ঠিকানাটি পাওয়া যাচ্ছে না, বা ইন্টারফেসটি নেই। বার্তাটি নির্দিষ্ট: ডেমন যে ঠিকানার চেষ্টা করেছে তা বলে; হোস্টে ip -br addr এর সঙ্গে তুলনা করলে বোঝা যায় ইন্টারফেসটির নাম বদলেছে, সরানো হয়েছে, নাকি পুরোনো ঠিকানা ছাড়াই চালু হয়েছে।

সারাক্ষণ একটি অনুমোদিত রিকভারি কনসোল খোলা রাখুন। আপনি যে বাইন্ডিং বদলাবেন তা যদি আপনার একমাত্র প্রশাসনিক সেশন বহন করে, তবে ফেরার পথ নিজেই কেটে ফেলেছেন। স্থানীয় কনসোল, দ্বিতীয় ব্যবস্থাপনা ঠিকানা বা নথিভুক্ত আউট-অব-ব্যান্ড পথ পরিবর্তনটিকে ফেরানোর যোগ্য করে।

সম্পাদনার আগে কনফিগারেশন জিজ্ঞাসা করুন

Access Server নিজের CLI দিয়ে তার কনফিগারেশন দেখায়। নথিভুক্ত দৃশ্যটি হলো:

sacli ConfigQuery

আপনার সংস্করণের জন্য নথিভুক্ত প্রশাসনিক পরিবেশে এটি চালান, অন্য হোস্টের অসম্পর্কিত শেল থেকে নয়। কিছু বদলানোর আগে বর্তমান মানগুলো সুরক্ষিত জায়গায় রাখুন, এবং সম্পূর্ণ আউটপুট প্রকাশ্য সহায়তা থ্রেডে পেস্ট করবেন না।

সেই আউটপুট সার্ভার কনফিগারেশনের দৃশ্য, সম্পূর্ণ ব্যাকআপ নয়। ব্যবহারকারী ও গ্রুপের বৈশিষ্ট্য আলাদাভাবে জিজ্ঞাসা করা হয়, তাই পরিষ্কার বাইন্ডিং পরিচয় ফেরায় না, আর ফেরানো পরিচয় লিসেনার ঠিক করে না। দুটোকে আলাদা নথি হিসেবে রাখুন।

কোন লিসেনারটি ভেঙেছে নির্ণয় করুন

Access Server একাধিক লিসেনার চালায়। OpenVPN ডেমনগুলো টানেল ট্রাফিক বহন করে, ওয়েব সেবা প্রশাসনিক ও ক্লায়েন্ট পোর্টাল, অন্য উপাদানের নিজস্ব পোর্ট থাকতে পারে। ব্যর্থ ব্রাউজার অনুরোধ কোনটি ব্যর্থ হলো তা বলে না, ত্রুটি বার্তার পোর্ট নম্বরও না।

ডেমন বাইন্ডিং কী-গুলো প্রতি ডেমনের জন্য নথিভুক্ত, আর সরকারি টিউটোরিয়ালে মানটি ইন্টারফেস শনাক্তকারী, যদিও কী-এর নাম ip_address দিয়ে শেষ হয়। কথাটি দুবার পড়ুন। টিউটোরিয়ালটি আশা করে UDP ও TCP ডেমন একটি ইন্টারফেস ভাগ করবে, তাই কেবল একটি কী ঠিক করা আধা মেরামত।

নামকৃত সেটিং বদলান, মিলে যাওয়া সারি নয়

টিউটোরিয়ালে ConfigPut নির্দিষ্ট কী-তে নথিভুক্ত, যেমন vpn.daemon.0.server.ip_address ও vpn.daemon.0.listen.ip_address। পণ্যের নিজস্ব পদ্ধতি কী-এর নাম ও নতুন মানসহ, আপনার সংস্করণে নথিভুক্ত সিনট্যাক্সে ব্যবহার করুন, এবং আপনি নির্ণয় করা লিসেনারের কী-গুলোই কেবল বদলান।

যা করবেন না তা হলো ডেটাবেসে পুরোনো ইন্টারফেস নামের সমান মান থাকা প্রতিটি সারি খুঁজে সবগুলো বদলে দেওয়া। এটি ধরে নেয় পুরোনো নাম কেবল লিসেনার সেটিংয়ে ছিল, যা স্কিমা প্রতিশ্রুতি দেয় না। এটি পরিবর্তনটিকে পর্যালোচনার অযোগ্যও করে।

আরও দুটি প্রলোভন প্রত্যাখ্যান করা উচিত। সব ইন্টারফেসে শোনা ডিফল্ট ফেরানো একটি এক্সপোজার সিদ্ধান্ত, বানান সংশোধন নয়; অভীষ্ট স্থানীয় বাইন্ডিং, প্রকাশিত পথ ও তার সামনের ফিল্টারিং সবই সেই পছন্দের সঙ্গে মিলতে হবে। কনফিগারেশন পুনরায় আরম্ভ করা সমস্যাটি সমাধান না করে নাম বদলায়, কারণ নতুন ইনস্টল নাম বদলের আগে কাজ করা ব্যবহারকারী ও অনুমতিগুলোই ফেলে দেয়।

প্রয়োগ করুন, তারপর পথটি কাজ করে প্রমাণ করুন

মান সংশোধনের পরে পণ্যের নথিভুক্ত জীবনচক্রের মাধ্যমে প্রয়োগ করুন ( জীবনচক্র )। টিউটোরিয়ালে কী বসানোর পরে sacli start ব্যবহার করা হয়; এটি সম্পূর্ণ হোস্ট রিবুট বা ডেটাবেস রিসেট নয়।

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

লিসেনার পরীক্ষা করুন, তারপর একটি অনুমোদিত VPN সংযোগ করুন, একটি ব্যক্তিগত সম্পদে পৌঁছান, এবং প্রশাসনিক পৃষ্ঠাটি তার প্রত্যাশিত পথে খুলুন। বর্তমান ব্যবহারকারী অনুমতি ও প্রত্যাহার রাখুন; সেগুলো রিসেট করা উদ্ধার বাইন্ডিং ঠিক করে স্থাপনাটি হারায়। কাজ শেষ হয় যখন একই সেবা তার অভীষ্ট ইন্টারফেসে কাজ করে।