VPN রুট নাকি ফায়ারওয়াল নিয়ম: প্যাকেটটি কোনটি ফেলছে?

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

দুটি সিদ্ধান্ত, একটি প্যাকেট, দুটি মালিক

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

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

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

অনুসন্ধান আসলে কী বেছে নিল তা পড়ুন

সিদ্ধান্তটি অনুমান না করে প্রিন্ট করুন। নিচের কমান্ডটি সেই গন্তব্যের জন্য কার্নেল যে রুট ব্যবহার করবে তা সমাধান করে, ইন্টারফেস এবং যে সোর্স বেছে নেবে তা সহ:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN ক্লায়েন্টরা প্রায়ই মূল টেবিলের নিচের প্রায়োরিটিতে নীতি নিয়ম ইনস্টল করে, তাই একটি পরিষ্কার মূল টেবিল একা নিজে কিছুই প্রমাণ করে না। নিয়মের প্রায়োরিটিগুলো তারা যে টেবিল বেছে নেয় তার সাথে তুলনা করুন, এবং টানেল রুটটি একবার হাতে যোগ করার বদলে পুনঃসংযোগের পর টিকে থাকে কি না দেখুন।

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

ফিল্টারিং প্রযোজ্য হয় একটি হুকে, রুটে নয়

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

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

ক্লায়েন্ট যে পথ ব্যবহার করে সেই পথে একটি প্রোব পাঠান

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

প্রতিটি পরিবর্তন এমন জায়গায় রাখুন যেখানে তা পুনঃসংযোগের পর টিকে থাকে

ip route add দিয়ে যোগ করা রুট ইন্টারফেস বন্ধ হওয়া পর্যন্ত বাঁচে। পরিবর্তে এটি সংযোগ প্রোফাইলে সংরক্ষণ করুন: NetworkManager সংযোগে অতিরিক্ত রুট গ্রহণ করে, এবং netplan বুটের মধ্যে সেগুলো রাখে। একই নিয়ম ক্লায়েন্ট-সাইড ফায়ারওয়াল ব্যতিক্রমে প্রযোজ্য, যা পরের রিলোডের পর চলে যায়।

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

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