VPN সংযুক্ত, তবু ফায়ারওয়াল আটকাচ্ছে: কোনটি দায়ী তা কীভাবে বুঝবেন

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

পথকে নীতি থেকে আলাদা করুন

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

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

একবারে পথটি পড়ুন

একটি নিয়মও দেখার আগে নিশ্চিত করুন টানেলটি গন্তব্য ঢাকছে। যে স্প্লিট টানেল শুধু অফিস সাবনেট বহন করে, সেটি অন্য রেঞ্জে অনুরোধ পাঠাবে না, আর তখন ব্যর্থতাটি ফায়ারওয়াল ব্লকের মতো দেখায়, যদিও তা নয়:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

রুটের আউটপুট বলে দেয় প্যাকেট কোন ইন্টারফেস দিয়ে বেরোবে এবং কোন সোর্স ঠিকানা বহন করবে। যদি সেই ইন্টারফেস টানেল না হয়ে আপনার ভৌত NIC হয়, তবে সমস্যা রাউটিং বা টানেলের অনুমোদিত রেঞ্জে, এবং তা ফায়ারওয়ালের নয়, VPN কনফিগারেশনের।

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

যে স্তর উত্তর দেয় সেই স্তরে নীতি পড়ুন

পথ ঠিক হয়ে গেলে হোস্ট থেকে বাইরের দিকে নীতি ধরে হাঁটুন এবং সেই একমাত্র স্তরটি দেখুন যার কাউন্টার নড়ছে:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

টানেল সেখানেই শেষ হলে গেটওয়ের সিদ্ধান্ত পড়ুন

সাইট-টু-সাইট বা রিমোট-অ্যাক্সেস গেটওয়েতে VPN একজন ব্যবহারকারীকে প্রমাণ করে এবং নীতি একটি রিসোর্সের অনুমোদন দেয়, আর এগুলো আলাদা অনুমতি। টানেলে ঢোকার অনুমতি পাওয়া ব্যবহারকারী স্বয়ংক্রিয়ভাবে প্রতিটি অভ্যন্তরীণ হোস্টে অনুমোদিত নন, আর প্রত্যাখ্যান প্রায়ই আসে ফরওয়ার্ডিং নিয়ম থেকে, যখন টানেল নিজেই সুস্থ। একই বিচ্ছেদ IPsec-এ দেখা যায়, যেখানে ট্রাফিক নির্বাচনকারী নিরাপত্তা নীতি সেটি গ্রহণকারী ফিল্টার থেকে আলাদা, আর সে কারণেই দুটিকে ভিন্ন প্রক্রিয়া হিসেবে RFC 4301.

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

গেটওয়ে সেই জায়গাও যেখানে NAT বা মাস্কারেড নিয়ম আসল সোর্স লুকাতে পারে। অভ্যন্তরীণ হোস্টগুলো ক্লায়েন্টের বদলে গেটওয়ের ঠিকানা দেখলে, ক্লায়েন্ট পুলের সঙ্গে মেলানো তাদের হোস্ট ফায়ারওয়াল নিয়ম কখনোই মিলবে না, আর সমাধান প্রতিটি সার্ভারে নয়, গেটওয়েতে।

সবচেয়ে সংকীর্ণ স্তর বদলান, তারপর যাচাই করুন

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

যে পরীক্ষা ব্যর্থ হয়েছিল সেই একই পরীক্ষায়, একই ক্লায়েন্ট থেকে যাচাই করুন, তারপর পুনঃসংযোগের পরে আরও একবার, কারণ টানেল নতুন করে দরকষাকষির আগে যে নিয়ম মিলত, তা পরে না-ও মিলতে পারে:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

বন্ধ করার আগে:

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