আপনার VPN হোস্ট করার আগে একটি VPS-কে কী কী অনুমতি দিতে হবে

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

প্রোটোকলের প্রয়োজনীয় ইন্টারফেস নিশ্চিত করুন

OpenVPN TUN-এর উপর চালাতে ক্যারেক্টার ডিভাইস এবং তার পেছনের কার্নেল মডিউল দরকার; WireGuard-এর দরকার নিজস্ব কার্নেল সমর্থন বা মিলে যাওয়া প্রত্যাশাসহ একটি ইউজারস্পেস বাস্তবায়ন। ম্যানেজড কন্টেইনারগুলি এমন হোস্ট কার্নেল শেয়ার করতে পারে যা ডিভাইসটি কখনো প্রকাশ করে না, এবং কিছু প্ল্যাটফর্ম যা-ই ইনস্টল থাকুক না কেন টানেল ইন্টারফেস তৈরি সম্পূর্ণ নিষিদ্ধ করে।

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

প্রথম জোড়ায় প্রত্যাখ্যান মানে TUN উপলব্ধ নয় এবং OpenVPN-এর ডিফল্ট মোড শুরু হতে পারে না; শেষ লাইনে প্রত্যাখ্যান মানে WireGuard কার্নেল ইন্টারফেস অনুপস্থিত। কার্নেল TUN/TAP ডকুমেন্টেশন প্রথম পরীক্ষা যে ডিভাইসটি যাচাই করে তা বর্ণনা করে। দুটি ব্যর্থতার কোনোটিই VPN প্যাকেজ পুনরায় ইনস্টল করে সারানো যায় না।

মনে রাখুন অন্তর্গামী পথের দুই মালিক আছে

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

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

ফিরতি পথের পরিকল্পনা করুন, কেবল প্রস্থানের নয়

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6-এর বিষয়টি স্পষ্টভাবে ঠিক করুন

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

প্রোভাইডার কোনো প্রিফিক্স রাউট না করলে ঠিক করুন টানেলটি কেবল IPv4 কি না এবং ক্লায়েন্টদের তা জানানো উচিত কি না। সংযুক্ত ব্যবহারকারীদের জন্য IPv6 গন্তব্যগুলো নীরবে কালোগর্তে ফেলে দেওয়া আংশিক কনফিগারেশনের চেয়ে নথিভুক্ত অনুপস্থিতি নিরাপদ।

বাইরের ক্লায়েন্ট থেকে এটি প্রমাণ করুন

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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