ইমপোর্ট করার আগে OpenVPN প্রোফাইলের সার্ভার যাচাই করবেন যেভাবে

কেউ আপনাকে একটি প্রোফাইল পাঠায়, আপনি তা ইমপোর্ট করেন, আর ত্রিশ সেকেন্ড পরে একটি ক্লায়েন্ট এমন গন্তব্যে ডায়াল করছে যা কেউ যাচাই করেনি। প্রথমে ফাইলটি টেক্সট এডিটরে পড়ুন, কারণ গুরুত্বপূর্ণ সবকিছুই কয়েকটি ডিরেক্টিভে থাকে: remote, proto, port, ca, cert, tls-crypt এবং verify-x509-name। বাকি সব ডিফল্ট, আর চমকগুলো ডিফল্টেই থাকে।

ফাইলটি যে সব এন্ডপয়েন্ট ব্যবহার করতে পারে তা তালিকাভুক্ত করুন

এন্ডপয়েন্ট দিয়ে শুরু করুন, কারণ একটি প্রোফাইলে কয়েকটি থাকতে পারে। grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn প্রতিটি প্রার্থী ফাইলের ক্রমে ছাপায়, ইনলাইন <connection> ব্লকের ভেতরে থাকাগুলোসহ।

যখন কোনো ডিরেক্টিভ পোর্ট বাদ দেয়, ক্লায়েন্ট লিসেনারের ডিফল্টে ফিরে যায়, তাই একা remote vpn.example.com মানে পোর্ট 1194, ফাইলে পরে যে proto-ই আসুক না কেন। কয়েকটি সাধারণ remote লাইন বিকল্প: ক্লায়েন্ট সেগুলো ক্রমে চেষ্টা করে যদি না remote-random সেগুলো এলোমেলো করে, আর এটি কখনো নীরবে অন্য অপারেটরের হোস্ট বসিয়ে দেয় না। সম্পর্কহীন ডোমেইনে দুটি remote লাইন সেই জায়গা যেখানে থেমে জিজ্ঞাসা করবেন কোনটি বোঝানো হয়েছে।

proto-এর বানানেও খেয়াল করুন। tcp ক্লায়েন্ট-পক্ষের tcp-client-এর সমার্থক হিসেবে গৃহীত, কিন্তু ক্লায়েন্ট প্রোফাইলে tcp-server একটি কনফিগারেশন ত্রুটি যা পরিষ্কারভাবে ব্যর্থ না হয়ে আটকে থাকার প্রবণতা রাখে।

আগে নাম, তারপর পোর্ট নিশ্চিত করুন

dig +short vpn.example.com বলে নামটি আছে কি না এবং কোন ঠিকানাগুলো ফেরত দেয়, আর মাল্টি-হোমড বা প্রক্সির পেছনের এন্ডপয়েন্ট বৈধভাবে কয়েকটি ফেরত দিতে পারে। নাম রিজলভ হওয়া পূর্বশর্ত, মালিকানার প্রমাণ নয়; যে কেউ একটি নামকে একটি ঠিকানায় নির্দেশ করতে পারে, আর একটি ঠিকানা অনেক নামের হয়ে উত্তর দিতে পারে।

তারপর যে পোর্ট পেয়েছেন সেখানে লিসেনার যাচাই করুন, ট্রান্সপোর্ট মিলিয়ে। TCP-তে openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com সার্ভার যে চেইন উপস্থাপন করে তা ছাপায়। UDP-তে DTLS দরকার: openssl s_client -dtls1_2 -connect vpn.example.com:1194 ডেটাগ্রাম জুড়ে একই হ্যান্ডশেক চালায়। সম্পূর্ণ হ্যান্ডশেক প্রমাণ করে কিছু শুনছে এবং একটি সার্টিফিকেট ধরে আছে, যা ping যা দেখায় তার চেয়ে বেশি এবং প্রোফাইলের নিজের ট্রাস্ট সেটিংস যা দাবি করে তার চেয়ে কম।

যখন হ্যান্ডশেক ব্যর্থ হয় আর হোস্ট ping-এ সাড়া দেয়, পোর্ট সম্ভবত ভুল বা ফিল্টার করা। এটিকে সঠিক পোর্ট চাওয়ার কারণ ধরে নিন, কাছের পোর্টগুলো ঝাড়ু দেওয়ার আমন্ত্রণ নয়। nc -vzu-ও কিছু স্ট্যাকে সফলতা জানায় যখন কিছুই শুনছে না, তাই পেছনে হ্যান্ডশেক ছাড়া শুধু UDP প্রোব কিছুই বোঝায় না।

ট্রাস্ট পিন ঠিকানা থেকে আলাদা করে পড়ুন

ঠিকানা নির্ধারণ করে ক্লায়েন্ট কোথায় যাবে; ট্রাস্ট ব্লক নির্ধারণ করে পৌঁছানোর পর সে কাকে বিশ্বাস করবে। verify-x509-name "vpn.example.com" name সাবজেক্টের সাধারণ নাম পিন করে, আর remote-cert-tls server সার্ভার প্রমাণীকরণের জন্য বর্ধিত কী ব্যবহার বাধ্যতামূলক করে। অপারেটরের দেওয়া প্রোফাইলে দুটোই থাকা উচিত।

ca, একটি ইনলাইন <ca> ব্লক, এবং tls-crypt বা tls-auth-এর যেকোনোটি খুঁজুন। tls-auth ব্যবহার করা প্রোফাইলে ক্লায়েন্টে key-direction 1 দরকার যখন সার্ভার পক্ষ দিক 0 ব্যবহার করে, আর অমিল হ্যান্ডশেককে TLS ত্রুটিতে ব্যর্থ করে যা সার্টিফিকেটের ত্রুটির মতো পড়া যায়। এমন ইনলাইন CA যা সেই অপারেটরের নয় যার নাম আপনি এইমাত্র রিজলভ করেছেন, মানে ফাইলটি দুটি উৎস থেকে জোড়া হয়েছে, আর এটাই সেই ক্ষেত্রে যা স্পষ্টভাবে প্রত্যাখ্যান করা উচিত।

verify-x509-name name, name-prefix বা subject মোড নেয়, আর শেষটি সার্ভার যে নিখুঁত ক্রমে ছাপায় সেই ক্রমে পূর্ণ বিশিষ্ট নাম আশা করে। এমন মোড বাছুন যা মানের আকারের সঙ্গে মেলে, কারণ ক্লায়েন্ট কাছাকাছি মিল নিয়ে সতর্ক করার বদলে প্রতিটি সংযোগ প্রত্যাখ্যান করে। যে ফাইল আপনি লেখেননি তার জন্য সাধারণ হোস্টনামসহ name সবচেয়ে কম বিস্ময়কর পছন্দ।

যে অপশনগুলো নীরবে ব্যর্থ হয় সেগুলো দেখুন

OpenVPN 2.6 data-ciphers-এর মাধ্যমে সাইফার নিয়ে দরকষাকষি করে, আর শুধু পুরোনো cipher AES-256-CBC লাইন থাকা প্রোফাইল নিয়ন্ত্রণ চ্যানেল শেষ করে ডেটায় আটকে যেতে পারে। ওই মান পড়লে বোঝা যায় ফাইলটি আপনি যে সার্ভারে যোগ দিচ্ছেন তার আগের কি না; 2.6-এর ম্যান পেজ দরকষাকষির ক্রম তালিকাভুক্ত করে যদি অপারেটরকে উদ্ধৃত করতে হয়।

ফাইলনাম ছাড়া auth-user-pass মানে ক্লায়েন্ট জিজ্ঞাসা করবে, তাই নিজে-সম্পূর্ণ দেখতে হওয়া প্রোফাইলেও শংসাপত্র লাগে। auth-user-pass credentials.txt মানে এটি এমন ফাইল আশা করে যা সম্ভবত আপনাকে পাঠানো হয়নি। nobind আর resolv-retry infinite সাধারণ ও নিরীহ, অথচ explicit-exit-notify শুধু UDP-র জন্য এবং TCP-তে অর্থহীন।

এর কোনোটিই বদলায় না প্রোফাইল কোথায় সংযোগ করে, কিন্তু প্রত্যেকটি বদলায় আদৌ সংযোগ করবে কি না, আর কোনোটিই ক্লায়েন্টের ইমপোর্ট ডায়ালগে দেখা যায় না।

সিদ্ধান্ত নিন, তারপর যা সিদ্ধান্ত নিলেন তা লিখে রাখুন

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

আপনি যে হ্যাশ দেখেছেন তা লিখে রাখুন, যাতে পরের ব্যক্তি বুঝতে পারে ফাইল বদলেছে কি না: sha256sum profile.ovpn, আপনার নোটে এন্ডপয়েন্টের পাশে লাগিয়ে দিন। প্রোফাইল ঠিকানার তালিকা নয়, একটি সম্পূর্ণ বিন্যাস, তাই কখনো কাজ করা remote কে অন্যের ট্রাস্ট ব্লকে তার শংসাপত্র রেখে জোড়া দেবেন না।

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

যদি ইমপোর্ট করেন আর প্রথম চেষ্টা ব্যর্থ হয়, ক্লায়েন্টটি --verb 3 দিয়ে চালান এবং প্রথম দশটি লাইন পড়ুন: রিজলভ হওয়া remote ঠিকানা, দরকষাকষি করা proto এবং TLS ত্রুটি ঠিক এই ক্রমে আসে, যা বলে দেয় উপরের কোন যাচাই আপনি বাদ দিয়েছেন।