MULTI: ক্লায়েন্ট থেকে ভুল উৎস ঠিকানা: এটি কার ঠিকানা ছিল?
ভেতরের উৎস যে ক্লায়েন্ট তা পাঠিয়েছে তার সঙ্গে মেলে না। এটি একটি টানেল বরাদ্দ, ক্লায়েন্টের পেছনের LAN, বা ডুপ্লিকেট পরিচয়ের সঙ্গে মিলিয়ে দেখুন।
সার্ভার লগ MULTI: bad source address from client ছাপে, প্যাকেটটি ফেলে দেয়, আর সেশন সংযুক্ত থাকে। এই সমন্বয়টি সেই মানুষদের বিভ্রান্ত করে যারা বার্তাটিকে প্রমাণীকরণের ব্যর্থতা হিসেবে পড়েন। তা নয়: ক্লায়েন্ট প্রমাণীকৃত হয়েছে, আর যে প্যাকেটটি এসেছে সেটি একটি ভেতরের উৎস ঠিকানা বহন করছিল যা সার্ভার ওই ক্লায়েন্ট ইনস্ট্যান্সের সঙ্গে যুক্ত করতে পারেনি। যাচাইটি ডেলিভারির আগে ঘটে, তাই টানেল সুস্থ দেখায় অথচ এর ভেতর দিয়ে উপকারী কিছুই যায় না।
ডেলিভারির আগে সার্ভার কী তুলনা করে
ক্লায়েন্ট থেকে আসা প্রতিটি প্যাকেটের জন্য ইউজার-স্পেস সার্ভার টানেলের ভিতরের উৎস ঠিকানাটি দেখে এবং তার অভ্যন্তরীণ রাউটিং অবস্থাকে জিজ্ঞাসা করে ওই ঠিকানাটি কোন ক্লায়েন্টের। মালিক যদি অন্য ইনস্ট্যান্স হয়, বা কোনো মালিকই না থাকে, প্যাকেটটি মুছে ফেলা হয় এবং সতর্কবার্তাটি জারি হয়।
টানেল ইন্টারফেসের মধ্য দিয়ে সাধারণ ডেলিভারি কখনোই ঘটে না।
এই ক্রমটি এমন একটি বিষয় ব্যাখ্যা করে যা মানুষকে হতবাক করে: হোস্টের ফায়ারওয়ালের কাউন্টার নড়ে না, কারণ প্যাকেটটি কখনোই ফায়ারওয়ালে পৌঁছায়নি। হোস্টে রিভার্স-পাথ ফিল্টারিং সামঞ্জস্য করলে এখানে কিছুই বদলায় না, কারণ প্রত্যাখ্যানটি ঘটেছে ডেমনটির নিজের সংযোগ-যাচাইয়ে। বার্তাটিকে মালিকানা সম্পর্কে একটি বিবৃতি হিসেবে পড়ুন, তারপর দেখুন তিনটি পরিস্থিতির কোনটি এটি তৈরি করেছে।
অমিল ভেতরের ঠিকানার তিনটি উৎস
ক্লায়েন্ট এমন ঠিকানা থেকে পাঠাতে পারে যা তাকে বরাদ্দ করা হয়নি, এমন নেটওয়ার্ক থেকে যা কেউ তার বলে ঘোষণা করেনি, বা এমন পরিচয়ের ডুপ্লিকেট থেকে যার ইতিমধ্যে মালিক আছে। তিনটিই একই লগ লাইন তৈরি করে। তারা আলাদা এই বিষয়ে যে আপনাকে কী বদলাতে হবে। ঠিকানা ও বর্তমান বরাদ্দের তালিকা দিয়ে শুরু করুন, এবং এই দুই তথ্যকেই কেসটি বেছে নিতে দিন।
এগুলো আলাদা করতে দুটি তথ্য লাগে: লগে প্রত্যাখ্যাত ঠিকানাটি, এবং সার্ভার যেসব বরাদ্দ বর্তমান বলে মনে করে। দ্বিতীয়টি চলমান ইনস্ট্যান্সের স্ট্যাটাস বা ম্যানেজমেন্ট ভিউ থেকে পাওয়া যায়, আর এটিই একমাত্র নির্ভরযোগ্য কর্তৃত্ব যা দেখার যোগ্য, কারণ কনফিগারেশন ফাইল বর্তমান অবস্থা নয়, ইচ্ছা লিপিবদ্ধ করে।
কিছু বদলানোর আগে দুটিই লিখে রাখুন, তারপর শ্রেণিবদ্ধ করুন। পরে নেওয়া স্ক্রিনশট সেই অবস্থার রেকর্ড নয় যা সতর্কবার্তাটি তৈরি করেছিল। টাইমস্ট্যাম্পও রাখুন, কারণ সেশনগুলোর মধ্যে বরাদ্দ সরে যায়।
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
ক্লায়েন্টের পেছনের LAN এবং iroute
যখন একটি সাইট ক্লায়েন্ট তার নিজের প্রাইভেট নেটওয়ার্ক রুট করে, সেই নেটওয়ার্কটিকে ক্লায়েন্টের বলে ঘোষণা করতে হবে। iroute এন্ট্রিসহ ক্লায়েন্ট-নির্দিষ্ট ফাইল তা করে, এবং এন্ট্রিটি সেই প্রিফিক্সের নাম দেয় যা বহন করার অনুমতি ক্লায়েন্টের আছে।
একই প্রিফিক্স টানেলের দিকে নির্দেশ করা কার্নেল রুট একটি আলাদা প্রয়োজনীয়তা, এবং এটি যোগ করলে ডেমনটির অভ্যন্তরীণ মালিকানায় কিছুই বদলায় না।
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0কার্যকর পরিচয়টি ফাইলের নামের সঙ্গে মেলে কিনা নিশ্চিত করুন, কারণ অমিল মানে ফাইলটি কখনো লোড হয় না এবং লক্ষণটি অনুপস্থিত এন্ট্রির মতোই। সতর্কবার্তা চুপ করাতে বিস্তৃত iroute যোগ করবেন না, কারণ তা একটি অপ্রত্যাশিত উৎসকে অনুমোদিত উৎসে পরিণত করে অথচ ক্লায়েন্ট কেন এটি পাঠাল তার উত্তর দেয় না। OpenVPN 2.6 ম্যানুয়াল iroute, duplicate-cn এবং পরিচয় ম্যাপিংকে আলাদা নিয়ন্ত্রণ হিসেবে নথিবদ্ধ করে।
দুই মেশিনে একই পরিচয়
দ্বিতীয় ল্যাপটপে কপি করা প্রোফাইল একই সার্টিফিকেট ও একই কমন নেম বহন করে। সার্ভারের সেটিংসের ওপর নির্ভর করে নতুন সংযোগটি পুরোটিকে প্রতিস্থাপন করতে পারে, আর যে ইনস্ট্যান্স মালিকানা ধরে রাখে সে-ই সংযোগ-যাচাইয়ে জেতে।
এটি ত্রুটিটিকে বিরতিহীন দেখায়, কেবল তখনই দেখা দেয় যখন দুটি ডিভাইসই জাগ্রত থাকে।
ডুপ্লিকেট কমন নেম অনুমোদন করলে দুটিই সংযোগ করতে পারে, কিন্তু তা তাদের স্বতন্ত্র স্ট্যাটিক ঠিকানা বা স্বতন্ত্র মালিকানা দেয় না। দুটি ডিভাইসকে একসঙ্গে থাকতে হলে তাদের আলাদাভাবে নথিভুক্ত করুন যাতে প্রত্যেকের নিজের পরিচয় ও নিজের বরাদ্দ থাকে। ডুপ্লিকেট সেটিংকে এই সতর্কবার্তার প্রতিকার ভাবলে রহস্যটি জায়গায় থাকে এবং আরেকটি যোগ হয়।
সংযোগ বদলেছে তা প্রমাণ করুন
কনফিগারেশনের মালিকের মাধ্যমে সংশোধনটি প্রয়োগ করুন, তারপর নতুন নীতি লোড হওয়ার জন্য আক্রান্ত ক্লায়েন্টকে আবার সংযুক্ত করুন।
একই প্রবাহ আবার চালান এবং তিনটি বিষয় নিশ্চিত করুন: প্যাকেটের ভেতরের উৎস, সার্ভার যে ক্লায়েন্ট ইনস্ট্যান্সের সঙ্গে এটি যুক্ত করে, এবং পরে গন্তব্যের আচরণ।
সতর্কবার্তা থেমে গেলেও অ্যাপ্লিকেশন যদি এখনও ব্যর্থ হয়, সমস্যাটি সরেছে, মিলিয়ে যায়নি। ফরওয়ার্ডিং, ফায়ারওয়াল নিয়ম এবং ফেরার পথ আলাদা স্তর, আর সংযোগ-যাচাই পেরোনো মানে কেবল প্যাকেটটিকে টানেল ছাড়ার অনুমতি দেওয়া হয়েছে।