প্রতিটি OpenVPN পিয়ারের কি সত্যিই remote লাইন দরকার? ঠিক তা নয়

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

remote আসলে কী নির্দিষ্ট করে

একটি remote এন্ট্রি একটি হোস্টের নাম দেয়, ঐচ্ছিকভাবে একটি পোর্ট ও একটি ট্রান্সপোর্ট, এবং ঐচ্ছিকভাবে এমন কয়েকটি এন্ট্রি যা ক্রমানুসারে চেষ্টা করা হয়।

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

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

তিনটি বিন্যাস উত্তর নির্ধারণ করে

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

সাধারণ গেটওয়েতে একটি নির্দিষ্ট ক্লায়েন্ট ঠিকানা পেস্ট করা সেই ভুল যা ওই শ্রেণিগুলি উপেক্ষা করা থেকে আসে। এটি সেই একটি পিয়ারের জন্য কাজ করে যার ঠিকানা লিপিবদ্ধ ছিল এবং বাকি সবাইকে বিভ্রান্ত করে।

নির্দেশিকায় এমন কিছু নেই যা কনফিগারেশনকে বহু-ক্লায়েন্ট সার্ভারে পরিণত করে, আর এর উপস্থিতিতে এমন কিছু নেই যা সার্ভার ভূমিকায় বাধা দেয়। OpenVPN 2.6 রেফারেন্স ঐচ্ছিক আর্গুমেন্ট এবং remote ছাড়া আচরণ আলাদাভাবে নথিভুক্ত করে, যা তাদের কতটা স্বাধীন তার একটি ইঙ্গিত।

ট্রান্সপোর্ট ভূমিকা আলাদা অক্ষ

TCP-তে এক পক্ষ অপেক্ষা করে আর অন্য পক্ষ সংযোগ স্থাপন করে। এগুলি গন্তব্য থেকে আলাদা নির্দেশিকা, এবং এদের মিশিয়ে দিলে এমন জোড়া তৈরি হয় যা দুটোই অপেক্ষা করে বা দুটোই সংযোগ স্থাপন করে।

TCP সোর্স-ফিল্টার ভূমিকাও আছে, তাই সার্ভারে কখনো remote থাকতে পারে না এই সরল বিবৃতিটি ভুল।

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

কেন remote-এর অনুপস্থিতি খোলা দরজা নয়

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

প্রমাণীকরণ ও গন্তব্য স্বাধীন, এবং বিশ্বাসের জন্য প্রথমটিই গুরুত্বপূর্ণ।

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

কনফিগারেশন যা ধরে নেয় তা লিখে রাখুন

প্রতিটি পক্ষের জন্য তিনটি জিনিস লিপিবদ্ধ করুন: প্রথম প্যাকেট কীভাবে পিয়ারে পৌঁছায়, কোন পক্ষ ট্রান্সপোর্ট গ্রহণ করতে পারে, এবং প্রতিটি পক্ষ অন্যটি সম্পর্কে কী যাচাই করে।

ওই অনুমানগুলিই নকশা। নির্দেশিকাগুলি কেবল তাদের বানান।

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