WireGuard ক্লায়েন্ট কি OpenVPN ক্লায়েন্টে পৌঁছাতে পারছে না?

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

লক্ষণে একবারে একটি অংশই অনুপস্থিত

এই নকশায় wg1 এর উপর 10.71.0.0/24 এর একটি WireGuard পুল এবং tun1 এর উপর 10.72.0.0/24 এর একটি OpenVPN পুল ব্যবহৃত হয়, দুটিই একটি গেটওয়েতে শেষ হয়। পরীক্ষাধীন অনুরোধটি 10.71.0.5 থেকে 10.72.0.30 এর HTTPS-এ যায়। নিচের প্রতিটি ধাপ সেই একটি প্রবাহ নিয়েই। প্রতিটি পরীক্ষার ব্যর্থতার স্বাক্ষর আলাদা, যদিও ব্যবহারকারী সেগুলো একইভাবে অনুভব করেন, এবং সাধারণত একবারে তিনটির মধ্যে কেবল একটি অনুপস্থিত থাকে।

আপনি শুরু করুন এই নিশ্চয়তা দিয়ে যে দুটি পুলই সত্যিই এই গেটওয়েতে আছে এবং টানেলগুলো যে namespace-এ থাকে সেখানে ফরওয়ার্ডিং সক্রিয়। যে গেটওয়ে দুটি প্রোটোকলকে আলাদা namespace-এ শেষ করে সে তাদের মধ্যে কিছুই ফরওয়ার্ড করে না, আর কোনও peer কনফিগারেশন পড়ার আগে সেটি বাদ দেওয়া উচিত।

স্পোকের গন্তব্য কভারেজ বাড়ান

WireGuard ক্লায়েন্টে, বিদ্যমান peer এন্ট্রিকে OpenVPN গন্তব্যের জন্য গেটওয়ে বেছে নিতে হবে, অর্থাৎ গন্তব্য প্রিফিক্সটি সেই peer এর অনুমোদিত তালিকায় দেখাতে হবে। এটি যোগ করলে দ্বিতীয় টানেল তৈরি হয় না; এটি বদলে দেয় ওই ঠিকানা খোঁজার সময় ক্লায়েন্ট কোন peer বেছে নেবে, আর wg-quick এর সঙ্গে রুট সাধারণত তালিকা অনুসরণ করে নিজে থেকেই।

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

আসল key ও endpoint লাইন অপরিবর্তিত রাখুন, এবং মনে রাখুন যে Table = off ব্যবহার করা ম্যানেজার এই তালিকা থেকে কোনও রুটই নেয় না। সেক্ষেত্রে একই প্রিফিক্সটি সিস্টেমের রুট টেবিলে ইনস্টল করতে হবে যার হাতে সেটির মালিকানা, আর সেখানে রুট অনুপস্থিত থাকলে তা হুবহু অনুমোদিত প্রিফিক্স অনুপস্থিত থাকার মতোই দেখায়।

গেটওয়েতে সোর্স মালিকানা ধরে রাখুন

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

AllowedIPs = 10.71.0.5/32

ওই এন্ট্রিকে রুটিং-সুবিধা নয়, মালিকানার ঘোষণা হিসেবে পড়ুন। ক্লায়েন্টকে আর যা কিছুতে পৌঁছাতে হবে তা ক্লায়েন্টের গন্তব্য তালিকায় থাকবে, এই peer কী পাঠাতে পারবে সে বিষয়ে গেটওয়ের ধারণায় নয়।

OpenVPN দিককে ফেরার রুট দিন

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

push "route 10.71.0.0 255.255.255.0"

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

শুধু যে একটি সেবার অনুমতি দিতে চেয়েছিলেন তারই অনুমতি দিন

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

এগুলো ফরওয়ার্ডেড নিয়ম, গেটওয়ের দুই VPN সেবার জন্য শোনার নিয়ম থেকে আলাদা। বাইরের UDP পোর্ট খুললে ভেতরের অনুরোধ অনুমোদিত হয় না, আর ভেতরের অনুরোধ অনুমোদন করতে গেটওয়েতে অবাধ SSH বা ফরওয়ার্ডিংয়ে ডিফল্ট allow দরকার হয় না। লক্ষ্যের নিজের ফায়ারওয়াল ও শোনার ঠিকানাও মিলতে হবে, কারণ loopback-এ বাঁধা সেবা সবচেয়ে যত্নে রুট করা প্যাকেটও প্রত্যাখ্যান করে। যে নীতি কথাবার্তার কেবল একটি দিক ঢাকে তা সাধারণত সফল অনুরোধ ও নীরব উত্তরে ব্যর্থ হয়, আর তিনটির মধ্যে এটিই সবচেয়ে বিভ্রান্তিকর ফল।

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