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

বাইন্ড ত্রুটি একটি লোকাল ঠিকানার নাম দেয়

যখন OpenVPN জানায় যে সে একটি লোকাল ঠিকানা বাইন্ড করতে পারছে না, তখন সে ট্রান্সপোর্ট সকেটের কথা বলছে: UDP বা TCP প্রান্তবিন্দু, যা এনক্রিপ্টেড সংযোগটি পিয়ারের কাছে বহন করে।

স্পষ্ট local নির্দেশ ডেমনকে সেই সকেট নির্দিষ্ট লোকাল ঠিকানায় বাইন্ড করতে বলে। ঠিকানাটি সেই নেটওয়ার্ক নেমস্পেসে থাকতে হবে যেখানে প্রক্রিয়াটি চলছে, এবং ক্লায়েন্ট শুরুর মুহূর্তে সেটি বরাদ্দযোগ্য হতে হবে।

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

local আর remote আসলে কী বেছে নেয়

remote যোগাযোগের পিয়ারের নাম দেয়। local একই সকেটের নিকট প্রান্ত বাইন্ড করে। nobind অপারেটিং সিস্টেমকে লোকাল ঠিকানা ও পোর্ট দুটোই বেছে নিতে দেয়, তাই বাড়ির রাউটারের পেছনের ক্লায়েন্টরা সাধারণত দুটি নির্দেশের কোনোটিই ছাড়া কাজ করে।

কোনো নির্দেশেরই টানেলের ভেতরের ঠিকানার সঙ্গে কোনো সম্পর্ক নেই।

কনটেইনার বা নেটওয়ার্ক নেমস্পেসে একই নিয়ম আরও সংকীর্ণ সীমার মধ্যে প্রযোজ্য: হোস্টের ঠিকানাগুলো ভেতরে থাকে না, তাই হোস্ট কনফিগারেশন থেকে কপি করা local লাইনটি ভুল ঠিকানার চেয়ে সম্পূর্ণ ভিন্ন কারণে ব্যর্থ হয়।

ip -brief address show
ip route get 203.0.113.10

ভেতরের ঠিকানা আসে সার্ভার থেকে

কন্ট্রোল চ্যানেল প্রতিষ্ঠার পরেই টানেলের ভেতরের ঠিকানা নিয়ে দর-কষাকষি হয় বা সেটি বরাদ্দ হয়। ডায়নামিক পুলে সার্ভার সংযোগের সময়েই তা ঠিক করে, আর ক্লায়েন্ট-নির্দিষ্ট কনফিগারেশনে তা প্রতিটি পরিচয়ের জন্য নির্দিষ্ট হতে পারে।

ভেতরের ঠিকানা দিয়ে local লেখা মানে সার্ভারকে সেই ঠিকানা বরাদ্দ করতে বলা নয়। সবচেয়ে ভালো ক্ষেত্রে বাইন্ড ব্যর্থ হয়; সবচেয়ে খারাপ ক্ষেত্রে ক্লায়েন্ট একই মানের একটি অসম্পর্কিত হোস্ট ঠিকানা খুঁজে পায় এবং ট্রান্সপোর্টের জন্য সেটি ব্যবহার শুরু করে।

যে ইন্টারফেসগুলো পড়তে হবে সেগুলোও আলাদা। ifconfig প্যারামিটার আর পুল কনফিগারেশন ভেতরের দিক বর্ণনা করে, অন্যদিকে remote, local, proto আর nobind বাইরের দিক বর্ণনা করে। দুটি তালিকা আলাদা রাখলে ফোরামে পাওয়া প্রায় প্রতিটি বিভ্রান্তিকর উদাহরণ ব্যাখ্যা হয়ে যায়। OpenVPN 2.6 ম্যানুয়াল এই কারণেই সেগুলো আলাদা অধ্যায়ে নথিভুক্ত করে।

ফাঁদ: নিজের ট্রান্সপোর্টকেই ধরে ফেলা পূর্ণ টানেল

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

ট্রান্সপোর্টকে যদি নির্দিষ্ট লোকাল ঠিকানায় পিন করেন আর পরে সেই ঠিকানার ব্যবহার করা পথ বদলান, তবে বাইরের সংযোগ পথ হারাতে পারে যদিও ভেতরটা কনফিগার করা থাকে। টানেল সংযুক্ত বলে রিপোর্ট করতেই থাকে, কারণ ভেতরে সব ঠিক আছে। কেবল ট্রান্সপোর্টটাই ভাঙা, আর তাই লগগুলো পরস্পরবিরোধী মনে হয়।

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

বিভ্রান্তি এড়ানোর একটি অভ্যাস

প্রোফাইলের প্রতিটি ঠিকানা পড়ুন এবং সম্পাদনার আগে সিদ্ধান্ত নিন সেটি কোন স্তরের।

যদি সেটি ট্রান্সপোর্টের দূর প্রান্তের নাম দেয় বা তার নিকট প্রান্ত বাইন্ড করে, তবে সেটি বাইরের ঠিকানা এবং শুরুর আগেই থাকতে হবে। যদি সেটি টানেলের ভেতরে যা ঘটে তা বর্ণনা করে, তবে সেটি আসে সার্ভার বা টপোলজি থেকে, এবং কোনো লোকাল নির্দেশ তার বিকল্প হতে পারে না।

দুটি তালিকা প্রোফাইলের পাশে ডিপ্লয়মেন্ট নোটে লিখে রাখুন। পরের ট্রাবলশুটিং সেশনটি তখন অনুমানের বদলে স্তর দিয়েই শুরু হবে।

সম্পর্কিত নিবন্ধ