কেন nftables OpenVPN ক্লায়েন্টদের পারস্পরিক ট্রাফিক দেখতে পায় না
পিয়ার ট্রাফিক VPN প্রসেসের ভেতরেই পৌঁছে দেওয়া হয়, তাই ফরওয়ার্ড কাউন্টার কখনও নড়ে না। এটি গুনতে হলে কার্নেল পথ আর প্রসেস পথের মধ্যে বেছে নিতে হয়।
একই সার্ভারে দুটি ক্লায়েন্ট ফাইল বিনিময় করে, স্থানান্তর সফল হয়, আর টানেলের দিকে দেখানো প্রতিটি ফরওয়ার্ড রুল শূন্য প্যাকেট রিপোর্ট করে। রুলগুলো নষ্ট নয় এবং চেইন ভুল জায়গায় নেই। পিয়ার-টু-পিয়ার ফরওয়ার্ডিং চালু থাকলে প্যাকেটটি সার্ভার প্রসেসের ভেতরেই পৌঁছে দেওয়া হয় এবং হোস্ট স্ট্যাক কখনও রাউটার হয় না, তাই কার্নেল ফায়ারওয়ালের গোনার মতো কিছু থাকে না। এই বিভাজন বুঝলে বোঝা যায় আপনি শর্টকাটটি রাখবেন, নাকি কার্নেল দিয়ে পথটি আবার গড়বেন।
সার্ভারের ভেতর দিয়ে একটি প্যাকেট অনুসরণ করুন
রাউটেড টানেলে ডেমন প্রতিটি ক্লায়েন্টের ডিক্রিপ্ট করা প্যাকেট টানেল ডিভাইসে দেয়। সেখান থেকে হোস্ট এটি রাউট করে, ফরওয়ার্ড হুক চলে, আর টানেল ডিভাইসের সঙ্গে মেলে এমন রুল ট্রাফিক গুনতে বা ফেলে দিতে পারে। বেশিরভাগ ফায়ারওয়াল উদাহরণ এই পথটাই ধরে নেয়।
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
শর্টকাটটি হোস্টকে মাঝখান থেকে সরিয়ে দেয়। এক সেশন থেকে ডিক্রিপ্ট করা প্যাকেট ডেমনোর ভেতরেই অন্য সেশনে দেওয়া হয়, আর ভেতরের প্যাকেট কখনও টানেল ডিভাইসে নির্গত হয় না বা হোস্ট দ্বারা রাউট হয় না। এনক্যাপসুলেটেড ট্রাফিক তবুও ফিজিক্যাল ইন্টারফেস পার হয়, তাই বাইরের ক্যাপচার ব্যস্ত দেখায়, অথচ ভেতরের রুলগুলো নীরব থাকে। টানেল ডিভাইসে নেওয়া ক্যাপচার একেবারেই কিছু দেখায় না, যা এমন যে কেউ সেখানে স্থানান্তর দেখতে আশা করে তাকে অবাক করে। এই অসামঞ্জস্যই ডেমনোর বাইরে থেকে শর্টকাটটি চেনার দ্রুততম উপায়।
কোন পথ চলেছে তা নির্ধারণকারী কাউন্টার পরীক্ষা
যে রুলটি প্রযোজ্য হওয়া উচিত তাতে একটি কাউন্টার লাগান, যে দুটি ক্লায়েন্টের মধ্যে ওই রুলের বাধা দেওয়া উচিত তাদের মধ্যে একটি স্থানান্তর চালান, আর পরে কাউন্টারটি পড়ুন।
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forwardযদি স্থানান্তর সফল হয় আর কাউন্টার শূন্যেই থাকে, তবে কার্নেল ওই প্যাকেটগুলো কখনও হ্যান্ডেল করেনি, এবং যতই রুল সম্পাদনা করুন তা বদলাবে না। একই পরীক্ষা সার্ভারের নিজের কোনো সার্ভিসের বিরুদ্ধে পুনরাবৃত্তি করুন, কারণ ওই ফ্লো হোস্ট স্ট্যাক পার হয় এবং তার কাউন্টার নড়ে। দুটি ফলাফল তুলনা করলেই উত্তর বের হয়।
দুটি বিষয় ভুল পাঠ আটকায়। চেইন লেবেলে লেখা ইন্টারফেসের নাম নিজে থেকে কিছু ফিল্টার করে না, কারণ মিল হয় রুলের ভেতরের ইন্টারফেস ফিল্ডে। আর ব্রিজ করা স্তর-2 নকশা আরও আলাদা আচরণ করে: সেখানে ক্লায়েন্টরা একটি ব্রডকাস্ট ডোমেইন ভাগ করে, তাই পিয়ার আবিষ্কার প্রত্যাশিত, রাউটিং ত্রুটি নয়।
সুইচ কোনো অ্যাক্সেস লিস্ট নয়
এটাই সেই অংশ যা একটি দুপুর খেয়ে ফেলে। পিয়ার ফরওয়ার্ডিং একটি একক চালু-বন্ধ সেটিং, আর যতক্ষণ তা চালু থাকে ডেমনোই একমাত্র ফরওয়ার্ডিং পয়েন্ট। হোস্ট ফায়ারওয়াল বলতে পারে না কে কার কাছে পৌঁছাতে পারবে, আর প্রতি-ক্লায়েন্ট ফাইল সুইচটিকে নীতিমালার ম্যাট্রিক্সে বদলে দেয় না।
প্রতি-পিয়ার রুল দরকার হলে বেছে নিতে হয় শর্টকাট ছাড়া, আর নিয়ন্ত্রণ হিসেবে হোস্ট ফায়ারওয়াল ছাড়া। এটি বন্ধ করলে কার্নেল ফরওয়ার্ডিং ফিরে আসে, যার জন্য সার্ভারে IP ফরওয়ার্ডিং চালু এবং আপনি যে ফ্লো চান তার জন্য স্পষ্ট রুল দরকার। এটি চালু রাখলে নীতিমালা থাকে ডেমনোর কনফিগারেশনে, যা বাস্তবে সব পিয়ার অথবা কোনো পিয়ার নয়।
নিজস্ব অ্যাড্রেস পুল ও পোর্টসহ আলাদা সার্ভার প্রসেস হলো কাজ চলে এমন মধ্যবর্তী পথ। প্রতিটি প্রসেস ঠিক একটি অ্যাক্সেস সিদ্ধান্ত বহন করে, তাই দুটি দল নীতিমালার ম্যাট্রিক্স ছাড়াই আলাদা রুল পেতে পারে। হোস্ট চাইলে পুলগুলোর মধ্যে রাউট করতে পারে, আর তখন ফায়ারওয়াল ওই ফ্লোগুলো দেখে কারণ সেগুলো হোস্ট পার হয়। খরচ হলো অতিরিক্ত পোর্ট, অতিরিক্ত সার্টিফিকেট এবং প্রতি দলের জন্য একটি প্রোফাইল।
ফরওয়ার্ডিং পয়েন্ট বেছে নেওয়া
কার্নেল ফরওয়ার্ডিং বেছে নিন যখন ফায়ারওয়ালই নীতিমালার ইঞ্জিন, যখন প্রতি ফ্লো-তে লগ দরকার, বা যখন হিসাব গুরুত্বপূর্ণ। খরচ হলো হোস্ট স্ট্যাক দিয়ে থ্রুপুট এবং রক্ষণাবেক্ষণের জন্য বেশি রুল। সুবিধা হলো কাউন্টার থেকে ফ্লো এক্সপোর্টার পর্যন্ত প্রতিটি বিদ্যমান টুল আবার ট্রাফিক বর্ণনা করে। ছোট সার্ভারে এই খরচ অদৃশ্য; ব্যস্ত রিলেতে তা নয়।
প্রসেসের ভেতরের ফরওয়ার্ডিং বেছে নিন যখন পিয়ার ট্রাফিক হয় সম্পূর্ণ অনুমোদিত, নয় সম্পূর্ণ নিষিদ্ধ এবং সার্ভার সেভাবেই মাপা। খরচ হলো কাউন্টার, কিউ শৃঙ্খলা ও কানেকশন ট্র্যাকিং আর ভেতরের ফ্লো বর্ণনা করে না; এটি গ্রহণযোগ্য কেবল যদি পরে কেউ ওগুলোর ওপর ভরসা না করে।
যা-ই বেছে নিন, ফায়ারওয়াল রুলের পাশে তা লিখে রাখুন। যে রুলসেট দেখে মনে হয় পিয়ার ট্রাফিক অনুমোদন করে, অথচ ডেমনো যেভাবেই হোক সিদ্ধান্ত নেয়, তা পরের যে ব্যক্তি ব্যর্থ স্থানান্তর ডিবাগ করবে তাকে বিভ্রান্ত করে। কেবল রুল পড়ে যে কেউ ধরে নেবে কার্নেলই দরজা।
রুল বদলানোর আগে কী যাচাই করবেন
সার্ভার সত্যিই যে কনফিগারেশন লোড করেছে তা পড়ুন, আপনার মনে থাকা সম্পাদিত ফাইল নয়, আর পিয়ার অপশনটি আছে কি না নিশ্চিত করুন। বদলে থাকলে নিশ্চিত করুন সার্ভিসটি রিলোড হয়েছে, শুধু ডিস্কে ফাইল আবার লেখেনি।
তারপর ক্লায়েন্ট-থেকে-সার্ভার ফ্লো দিয়ে পরীক্ষাটি পুনরাবৃত্তি করুন যাতে প্রমাণ হয় রুলটি আদৌ মেলে, এবং পুশ করা রুটগুলো দেখুন, কারণ অনুপস্থিত রুট ক্লায়েন্টের দিক থেকে ঠিক ফায়ারওয়াল ব্লকের মতোই দেখায়। কোন ফরওয়ার্ডিং পয়েন্ট সিদ্ধান্তের মালিক তা জানার পরেই রুলের ক্রম বদলান।