ipp.txt-এ একটি লাইন সম্পাদনা করা ঠিকানা সংরক্ষণ করার মতো মনে হয়, কিন্তু তা নয়। ifconfig-pool-persist দ্বারা নামকৃত ওই ফাইলটি রেকর্ড করে একটি সাধারণ নাম গতবার কোন ঠিকানায় ছিল, যাতে পুলটি সুবিধাজনক হলে সেই একই ঠিকানা ফিরিয়ে দিতে পারে। এর ভেতরে কিছুই পরের সংযোগকে ওই নম্বরে বেঁধে রাখে না।

নিচের পরীক্ষাগুলো ক্রমানুসারে চালান। প্রতিটি হয় প্রক্রিয়াটি নিশ্চিত করে, নয়তো আপনাকে থামতে ও একটি ইনপুট মেরামত করতে বলে।

স্থায়িত্ব ফাইলটি কী কাজে

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

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

সঠিক ক্লায়েন্ট নির্বাচিত হয়েছে কি না পরীক্ষা করুন

স্পষ্ট বরাদ্দ ক্লায়েন্টের সাধারণ নাম দিয়ে খোঁজা হয়, তাই ভুল পরিচয়ের জন্য নামকৃত ফাইল কখনোই পড়া হয় না। সার্ভার ওই ক্লায়েন্টের নাম কী মনে করে তা নিশ্চিত করুন, বিশেষত যেখানে username-as-common-name প্রমাণীকরণের পরে তা বদলে দেয়। তারপর নিশ্চিত করুন যে ফাইলের নাম ওই মানের সঙ্গে হুবহু মেলে, অক্ষরের বড়-ছোটসহ।

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

সংখ্যাগুলো টপোলজির সঙ্গে মেলে কি না পরীক্ষা করুন

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

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

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

নতুন সংযোগে ফলাফল পরীক্ষা করুন

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

প্রমাণগুলো একসঙ্গে রাখুন: ক্লায়েন্টের নাম, যে ফাইলটি মিলেছে, বরাদ্দ করা ঠিকানা এবং এটি যে পুল থেকে এসেছে।

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

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