WireGuard পূর্ণ টানেল: AllowedIPs 0.0.0.0/0 যথেষ্ট নয়

পিয়ারের AllowedIPs-এ 0.0.0.0/0, ::/0 রাখাই সেই ধাপ যা সবাই মনে রাখে, আর এটি কেবল ঠিক করে পিয়ার কোন ট্রাফিক বহন করতে পারবে। এই প্রিফিক্সগুলো কোনো রুট তৈরি করে না, অপর প্রান্তে কিছু ফরওয়ার্ড করে না, এবং প্রতিটি অ্যাপ্লিকেশনের রিজলভারকে যেখানে ছিল সেখানেই রেখে দেয়। পূর্ণ টানেলকে সত্যিই পূর্ণ হতে চারটি আলাদা বিষয় একসাথে সত্য হতে হবে, এবং সেগুলো নিচের ক্রমে যাচাই করা ভালো, কারণ পরের যাচাই আগেরটিকে বাঁচাতে পারে না। নিচের প্রতিটি যাচাই এমন তথ্য যা আপনি মেশিন থেকে পড়তে পারেন, এমন কোনো সেটিং নয় যা প্রয়োগ হয়েছে বলে আপনি আশা করেন।

পিয়ার প্রিফিক্স কী বেছে নেয়, আর কী নেয় না

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

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

ক্লায়েন্টকে রাউট করা, শুধু পিয়ার তালিকা নয়

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

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

কাজটা দুটি বিবরণ বহন করে। Address হলো একক হোস্ট প্রিফিক্স, ক্লায়েন্টের নিজের বলে মনে করা সাবনেট নয়, আর ম্যানেজারই ডিফল্ট AllowedIPs-কে প্রকৃত ডিফল্ট রুটে রূপান্তর করে। একই ফাইল ip link এবং wg setconf দিয়ে তুলুন এবং কোনো রুটই দেখা যাবে না, যা ভাঙা টানেলের মতো দেখায়, অথচ রাউটিং ধাপ বাদ পড়া একটি সুস্থ টানেল। wg-quick ম্যানুয়াল রাউটিং এবং Table আচরণ নথিভুক্ত করে যা ওই ম্যানেজারগুলো যোগ করে।

ফাইলের বদলে ফলাফল পড়ুন: ip route get 1.1.1.1 টানেল ইন্টারফেসের নাম বলবে, আর wg show চলমান ট্রান্সফার কাউন্টারসহ সাম্প্রতিক হ্যান্ডশেক দেখাবে। রুট ছাড়া হ্যান্ডশেক মানে ম্যানেজার কখনও চলে নি, আর প্রোফাইল আবার সম্পাদনা করলে তা ঠিক হবে না। ব্যবহারকারী যেভাবে ইন্টারফেস তুলবে ঠিক সেভাবেই তুলুন, নইলে পরীক্ষাটি ডিপ্লয়মেন্টের বদলে আপনার শেল মাপবে।

এন্ডপয়েন্টকে টানেলের বাইরে রাখা

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

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

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

গেটওয়েতে ফরওয়ার্ডিং ও উত্তরের পথ

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS ও ব্যর্থতার অবস্থা, আলাদাভাবে পরীক্ষিত

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

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

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