OpenVPN AF_INET সতর্কতা: নিরীহ ফলব্যাক, নাকি ব্যর্থ সকেট?

OpenVPN লগের দুটি লাইন একই শব্দে শুরু হয়, আর তাদের মধ্যে কেবল একটি সমস্যার কথা জানায়। Could not determine IPv4/IPv6 protocol. Using AF_INET একটি ফলব্যাক বিজ্ঞপ্তি: প্রোফাইলটি ঠিকানা-পরিবার খোলা রেখেছিল, তাই ডেমন একটি বেছে নিয়ে চালিয়ে গেছে। ব্যর্থতার শাখাটি জানায় যে কোনো সকেট তৈরি হয়নি এবং পুনরায় চালু করতে বলে। সাধারণ উপসর্গের পরের সবকিছুই তাদের আলাদা করে, তাই কিছু বদলানোর আগে তার পরের অংশ পড়ুন।

ফলব্যাক বিজ্ঞপ্তি কী জানায়

OpenVPN proto udp4 বা proto udp6 দিয়ে স্পষ্ট পরিবার গ্রহণ করে, আর স্টার্টআপে পরিবার নির্ণয় করার কথা হলে proto udp গ্রহণ করে। দ্বিতীয় ক্ষেত্রে ডেমন স্থানীয় বাইন্ড তথ্য পরীক্ষা করে বেছে নেয়।

এই নির্ণয় কাজ করলে সতর্কতাটি বলে কোন দিকে গেল, আর প্রক্রিয়াটি সকেট তৈরি করতে এগোয়। দুই-স্ট্যাক হোস্টে proto udp সহ একটি সার্ভার প্রায়ই এভাবেই IPv4-এ পৌঁছায়। সেই পথে কিছুই ত্রুটি নয়, আর তাতে হামলা, অনুপস্থিত ওয়েব সার্ভার বা প্রত্যাখ্যাত অ্যাকাউন্টের কোনো ইঙ্গিত নেই। লাইনটি কেবল এই কারণে কাজে লাগে যে পরের পরীক্ষাগুলো এতে উল্লিখিত পরিবারের সঙ্গে তুলনা করা উচিত।

এটিকে একটি প্রশ্নের উত্তর হিসেবে দেখুন, রোগনির্ণয় হিসেবে নয়। এটি বলে এই প্রক্রিয়া কোন পরিবার বেছে নিয়েছে, আর ক্লায়েন্ট কেন সংযোগ করতে পারছে না সে সম্পর্কে কিছুই বলে না।

ব্যর্থতার শাখা কেমন দেখায়

একই সকেট কোডে পরে এমন একটি শাখা আছে যেখানে আদৌ কোনো সকেট নেই। এটি সংক্ষিপ্ত ঠিকানা-পরিবারের বার্তা লেখে এবং পুনরায় চালু করতে বলে, কারণ চালিয়ে যাওয়ার কিছু বাকি নেই। শুরুর শব্দগুলো ফলব্যাকের সঙ্গে মেলে, ফলাফল মেলে না।

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

grep-এ পাওয়া একটি মিলও শাখা শনাক্তকরণ নয়। বাক্যটি ঘোরানো সারসংক্ষেপে, ভাঙা লাইনে এবং মানুষে দ্বিতীয় হাত থেকে পেস্ট করা লগের অংশে দেখা যায়, তাই একক মিল নয়, পাশের লাইন ও টাইমস্ট্যাম্পের ক্রম পড়ুন।

সতর্কতার বদলে লিসেনার দেখুন

চলমান সার্ভার লগের লেখা থেকে অনুমান না করেই পরিবার-প্রশ্নের সরাসরি উত্তর দেয়।

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

প্রোফাইলের সঙ্গে পরিবার, ঠিকানা ও পোর্ট মিলিয়ে দেখুন। 0.0.0.0:1194 সারিটি কেবল IPv4, আর দুই-স্ট্যাক হোস্টে [::]:1194 সারি bindv6only সেটিংসের ওপর নির্ভর করে দুই পরিবারই গ্রহণ করতে পারে। যদি প্রোফাইলে udp থাকে আর সকেট IPv4 হয়, তবে যাদের রিজলভার কেবল AAAA রেকর্ড ফেরায় সেই ক্লায়েন্টরা টানেল নিয়ে আলোচনার আগেই ব্যর্থ হবে।

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

কখন পরিবার জোর করে নির্ধারণ করা ঠিক

proto udp4 পিন করা শুধু-IPv4 স্থাপনার জন্য উপযুক্ত: শুধু A-ধরনের DNS নাম, একটিমাত্র v4 ঠিকানার ফায়ারওয়াল নিয়ম, শুধু v4 ঠিকানা দেওয়া অপারেটরদের পেছনের ক্লায়েন্ট। এটি অস্পষ্টতা দূর করে এবং পরের লগ লাইনগুলোকে পূর্বানুমেয় করে।

একই যুক্তি IPv6-অগ্রাধিকার পরিবেশের জন্য উল্টো দিকে কাজ করে, আর শুধু A-ধরনের ক্লায়েন্ট বেসের সামনে udp6 নিজের তৈরি বিভ্রাট। কেবল একটি নিরীহ সতর্কতা চুপ করাতে পরিবার জোর করা এই ভুলের চিরাচরিত রূপ, কারণ শান্ত লগের বিনিময়ে কে সংযোগ করতে পারবে তা আপনি বদলে দিয়েছেন।

শেষপ্রান্ত ও যেসব ক্লায়েন্টকে সেখানে পৌঁছাতে হবে তাদের ভিত্তিতে বাছুন। OpenVPN 2.6 ম্যানুয়াল পরিবহন রূপগুলো নথিভুক্ত করে, আর বার্তাটি সেই বাছাইয়ের ফল, তার ইনপুট নয়।

রেকর্ড সংকীর্ণ রাখুন

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

এই সতর্কতার সঙ্গে আসা প্যাকেজ প্রস্তাবগুলো অসম্পর্কিত, যতক্ষণ না কোনো ত্রুটি অনুপস্থিত কোনো এক্সিকিউটেবলের নাম বলে।

ifconfig সত্যিই অনুপস্থিত হলে স্ক্রিপ্ট যখন এটি ডাকে তখন ডেমন নাম ধরে তা বলে, আর সেটি আলাদা তদন্তের দাবি রাখে। AF_INET লাইন আর অনুপস্থিত একটি ইউটিলিটি ভিন্ন ব্যর্থতা, আর সতর্কতা বদলায় কি না দেখতে কিছু ইনস্টল করা—এভাবেই পরিচ্ছন্ন হোস্ট অপরিচ্ছন্ন হয়ে ওঠে।