.ovpn ফাইলে আসলে কী থাকে, আর কী করতে পারে না
.ovpn ফাইল আপনার ক্লায়েন্ট কনফিগার করে, সার্ভার নয়। এর ট্রান্সপোর্ট, কী ও রাউটিং লাইনগুলো কী করতে পারে এবং কোথায় তাদের প্রভাব শেষ হয় তা দেখুন।
বেশিরভাগ মানুষ মনে করেন .ovpn ফাইল একটি VPN কনফিগার করে। তা নয়: এটি একটি ক্লায়েন্ট কনফিগার করে, আর এটি যা চায় তার সবকিছুই অন্যপ্রান্তে আগে থেকেই থাকতে হবে। ফাইলে একটি লাইন বদলালে আপনার মেশিন কী চেষ্টা করবে তা বদলাতে পারে, কিন্তু সার্ভার কী অফার করে তা কখনোই নয়। এই পার্থক্যই ইমপোর্ট বা সংযোগে ব্যর্থ প্রোফাইল নিয়ে বেশিরভাগ বিভ্রান্তির ব্যাখ্যা দেয়।
ফাইলটিকে আপনার ক্লায়েন্টের প্রতি নির্দেশিত অনুরোধের তালিকা হিসেবে পড়ুন, তাহলে এর বেশিরভাগ লাইন স্পষ্ট হয়ে যাবে।
ফাইল আপনার ক্লায়েন্টের বর্ণনা দেয়, সার্ভারের নয়
একটি প্রোফাইল remote এন্ডপয়েন্ট, একটি ট্রান্সপোর্ট, একটি ইন্টারফেস প্রকার, পরিচয়ের উপাদান এবং অপারেটরের চাওয়া যেকোনো ক্লায়েন্ট-পার্শ্ব আচরণ একসাথে বাঁধে। প্রতিটি লাইন চালুর সময় ক্লায়েন্ট সম্পাদন করে। এর কোনোটিই কনফিগারেশন পরিবর্তন হিসেবে সার্ভারে পৌঁছায় না, আর কোনোটিই এমন কোনো লিসেনার তৈরি করতে পারে না যা আগে থেকে চলছে না। এমন একটি প্রোফাইল যা TCP 443 উল্লেখ করে এমন সার্ভারের বিপরীতে যা কেবল UDP 1194-এ শোনে প্রথম প্যাকেটেই ব্যর্থ হয়।
এই কারণেই একই ফাইল দুটি ক্লায়েন্টে ভিন্নভাবে আচরণ করে: ফাইল অনুরোধ করে, আর ক্লায়েন্ট সিদ্ধান্ত নেয় অনুরোধের কতটা সে মানতে পারবে।
ট্রান্সপোর্ট লাইনগুলোকে আগে থেকেই থাকা লিসেনারের সঙ্গে মিলতে হবে
proto এবং remote লাইনকে সার্ভার আসলে যা বাইন্ড করে তার সঙ্গে মিলতে হবে। UDP স্বাভাবিক পছন্দ, কারণ হারানো ডেটাগ্রাম টানেলকে আটকে দেয় না, অন্যদিকে TCP সীমাবদ্ধ নেটওয়ার্কে টিকে থাকতে পারে টানেলের ভেতরে হেড-অব-লাইন ব্লকিংয়ের বিনিময়ে। প্রোফাইল UDP থেকে TCP-তে বদলালে সার্ভার TCP গ্রহণ করে না; এটি কেবল ক্লায়েন্টকে এমন পোর্টে পাঠায় যা কেউ পড়ছে না।
পোর্ট 443 জনপ্রিয় কারণ এটি এমন নেটওয়ার্ক পেরোয় যেগুলো প্রায় আর কিছুই অনুমোদন করে না, আর এটি OpenVPN সেশনই থাকে, HTTPS অনুরোধ নয়। অপারেটর যদি একাধিক remote লাইন প্রকাশ করে, ক্লায়েন্ট সেগুলো ক্রমে চেষ্টা করে, যা লোড-ব্যালান্সিং সিদ্ধান্ত নয় বরং ফলওভার তালিকা। অপারেটর যেসব সমন্বয় দিয়েছে সেগুলোই রাখুন, এক এন্ট্রির হোস্টের সঙ্গে অন্য এন্ট্রির পোর্ট মিশিয়ে দেবেন না।
এমবেড করা কী ফাইলটি সামলানোর ধরন বদলে দেয়
সার্টিফিকেট ও কী <ca>, <cert> এবং <key> ট্যাগের মধ্যে ইনলাইন থাকতে পারে, অথবা আলাদা ফাইল হিসেবে উল্লেখ করা যেতে পারে। ইনলাইন উপাদান প্রোফাইলকে স্বনির্ভর করে এবং একইসঙ্গে এটিকে গোপন করে, কারণ ক্লায়েন্টের প্রাইভেট কী এর ভেতরেই যায়। CA সার্টিফিকেট সরকারি বিশ্বাস উপাদান এবং শেয়ার করা নিরাপদ; প্রাইভেট কী নয়, এমনকি এটি যখন অপাঠ্য টেক্সটের ব্লকের মতো দেখায় তখনও।
কী রক্ষা করা পাসফ্রেজ অ্যাকাউন্ট পাসওয়ার্ড থেকে আলাদা গোপনীয়তা, আর দুটো গুলিয়ে ফেললে প্রমাণীকরণ ব্যর্থ হয় যা ভুল ক্রেডেনশিয়ালের মতো দেখায়।
রুট ও DNS হয়তো ফাইল থেকেই আসে না
রাউটিং সার্ভার ঠেলে দিতে পারে, প্রোফাইল redirect-gateway দিয়ে সেট করতে পারে, বা ক্লায়েন্টের নিজস্ব ডিফল্টে ছেড়ে দেওয়া যায়। তাই আপনি যে ফাইল নামিয়েছেন তা টানেল ওঠার পর ট্রাফিক কোথায় যাবে তা পুরোপুরি নির্ধারণ করে না। যখন অভ্যন্তরীণ নাম রিজলভ হয় আর সরকারি সাইট হয় না, তখন স্প্লিট-টানেল নীতি যা করার জন্য তৈরি হয়েছিল তাই করছে, ব্যর্থ হচ্ছে না।
DNS একই ধরন অনুসরণ করে: ঠেলে দেওয়া dhcp-option DNS ক্লায়েন্ট প্রয়োগ করতে পারে, উপেক্ষা করতে পারে, বা স্থানীয় রিজলভার ম্যানেজার তা প্রতিস্থাপন করতে পারে। প্রোফাইল আবার পড়ার বদলে সংযোগের পর রিজলভারের অবস্থা দেখুন।
অসমর্থিত অপশন ক্লায়েন্ট সংস্করণের প্রশ্ন
ইমপোর্টের সতর্কবার্তা সাধারণত বোঝায় ক্লায়েন্ট কোনো নির্দেশনা বাস্তবায়ন করে না, ফাইল নষ্ট নয়। ডেস্কটপ ক্লায়েন্ট নথিভুক্ত নিয়ন্ত্রণে স্ক্রিপ্ট ও প্লাগইন চালাতে পারে, অন্যদিকে মোবাইল ক্লায়েন্ট সীমিত সেট গ্রহণ করে এবং যেসব লাইন বোঝে না সেগুলো নীরে বাদ দিতে পারে। পুরোনো ক্লায়েন্ট যে সাইফার বা TLS সেটিং প্রত্যাখ্যান করে তা সংস্করণের সমস্যা, অপারেটরের সঙ্গে সমাধান করুন। অচেনা বিশেষাধিকার চালু করে ইমপোর্ট জোর করে করলে সতর্কবার্তার বিনিময়ে আরও বড় আক্রমণ-তল পাওয়া যায়।
তুলনার জন্য মূল ফাইলটি রাখুন, অনুরোধে অবিকল অসমর্থিত নির্দেশনাটি উল্লেখ করুন, এবং আপনি যে ক্লায়েন্ট সত্যিই চালান তার জন্য তৈরি প্রোফাইল চান।
যেকোনো প্রতিস্থাপনের পর অ্যাপ কোন প্রোফাইল এন্ট্রি ব্যবহার করছে তা নিশ্চিত করুন, কারণ নতুন ফাইল ইমপোর্ট করলে পুরোনোটি সবসময় লেখা হয় না।