VPN ক্লায়েন্টদের টানেলে একে অপরের কাছে পৌঁছানো বন্ধ করুন

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

শেয়ার করা সেবার রুট পিয়ারদের মধ্যে অনুমতি নয়

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

তাই যে আইসোলেশন পরীক্ষা কেবল রুট পড়ে, তা কিছুই প্রমাণ করে না। /24 প্রতিটি ক্লায়েন্টে পাঠানো যায়, অথচ প্রতিটি পিয়ার-থেকে-পিয়ার প্যাকেট ফরওয়ার্ড হুকে ফেলে দেওয়া হয়। বিপজ্জনক ঘটনা উল্টোটি: কোনো স্পষ্ট নিয়ম নেই, অনুমোদনশীল ডিফল্ট আছে, এবং আইসোলেশন কেবল এই কারণে টিকে আছে যে কেউ তা পরীক্ষা করেনি।

টার্মিনাল খোলার আগে প্রয়োজনটি এক লাইনে লিখুন। সেবা ব্লক ও জাম্প হোস্টে পৌঁছান, ক্লায়েন্ট ব্লকের ভিতরে আর কোথাও পৌঁছাবেন না।

কে আসলে পিয়ার প্যাকেট ফরওয়ার্ড করে তা বের করুন

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

WireGuard প্রথম দলভুক্ত: এতে পিয়ার-থেকে-পিয়ার সুইচ নেই, তাই 10.8.0.4 থেকে 10.8.0.5-এ প্যাকেট wg0-তে আসে, ফরওয়ার্ড হুকে আঘাত করে এবং AllowedIPs দুটি ঠিকানা ঢাকলে আবার wg0 দিয়ে রুট হয়। OpenVPN দ্বিতীয় দল, যখন সার্ভার কনফিগে client-to-client সেট থাকে, কারণ ওই নির্দেশ প্যাকেটটি ব্যবহারকারী স্পেসে সেশনগুলোর মধ্যে হস্তান্তর করে। কিছু লেখার আগে লোড করা কনফিগে ওই নির্দেশটি দেখে নিন। যে কার্নেল নিয়ম কখনো ট্রাফিক দেখে না, তাকে কাজ করা নিয়ম থেকে আলাদা করা যায় না, আর ঠিক এভাবেই একটি ডিপ্লয়মেন্ট কোনো আইসোলেশন ছাড়াই শেষ হয়।

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

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

প্রতিটি ঠিকানাকে এমন পরিচয় দিন যা নিজে বাতিল করা যায়

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

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

নিষেধটি সেখানে রাখুন যেখানে প্যাকেট টানেল অতিক্রম করে

যে গেটওয়ে WireGuard ট্রাফিক ফরওয়ার্ড করে, সেখানে দুটি নিয়ম ঘটনাটি ঢাকে: সেবা ব্লকের অনুমতি দিন, তারপর ক্লায়েন্ট ব্লকের বাকিটা ফেলে দিন। ইন্টারফেস জোড়া ঠিকানার মতোই গুরুত্বপূর্ণ, কারণ কেবল গন্তব্যে মিললে LAN থেকে আসা ট্রাফিকও ধরা পড়ে। অনুমতিটি আগে যাচাই হয় যাতে ওই ক্রমে সেগুলো লোড করুন।

nftables-এ জোড়াটি বিদ্যমান inet filter টেবিলে যায়, আগে অনুমতি, পরে ফেলে দেওয়া। দুটি মিলই ঠিকানার সঙ্গে ইন্টারফেস জোড়া পিন করে।

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

লোড করার পরে প্রস্থান অবস্থায় ভরসা না করে চেইনটি আবার পড়ুন, এবং দুটি নিয়ম আপনার ইচ্ছাকৃত ক্রমে আছে তা নিশ্চিত করুন। IPv6 পুলের জন্য মিলে যাওয়া ip6 নিয়ম যোগ করুন, নয়তো ডুয়াল-স্ট্যাক টানেলে v4 জোড়াটি কেবল সাজসজ্জা। সার্ভারের ইতিমধ্যে অনুমোদনশীল ফরওয়ার্ড নীতি থাকলে চেইনটি পুরোপুরি বদলানোর বদলে ফেলে দেওয়াটি যোগ করুন।

যখন OpenVPN-এ client-to-client সক্রিয়, এই ফরওয়ার্ড নিয়মগুলো কখনো পিয়ার ট্রাফিকে মেলে না এবং নিষেধটিকে ডেমনটির নিজের নিয়ন্ত্রণে থাকতে হয়। হোস্টের প্রতি ঠিকানা করা ট্রাফিকের জন্য কার্নেল নিয়মগুলো রাখুন, কিন্তু সেগুলোকে আইসোলেশন নিয়ন্ত্রণ হিসেবে গণনা করবেন না।

নিষেধটি সার্ভার থেকে নয়, ক্লায়েন্ট থেকে প্রমাণ করুন

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

অনুমতিপ্রাপ্ত ক্লায়েন্ট থেকে নিশ্চিত করুন সেবাটি তার পোর্টে উত্তর দিচ্ছে। একই ক্লায়েন্ট থেকে পিয়ার ঠিকানাটি চেষ্টা করুন এবং প্রত্যাখ্যানের বদলে নীরব ফেলে দেওয়া আশা করুন:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

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