অফিসের লোকাল নেটওয়ার্কে VPN ক্লায়েন্ট কেন প্রতিটি উত্তর হারায়
অফিসের লোকাল নেটওয়ার্কে এবং একই সাবনেটের একটি টানেলে থাকা ল্যাপটপ ভুল ইন্টারফেস থেকে উত্তর দেয়। শিথিল রিভার্স-পাথ ফিল্টারিং এই নীরবতার ব্যাখ্যা দেয়।
একটি ল্যাপটপ ইথারনেট দিয়ে অফিসের /24-এ বসে আছে এবং একই /24-এ থাকা একটি OpenVPN সার্ভারেও যোগ দেয়। একজন সহকর্মী টানেল ঠিকানায় পিং করেন; অনুরোধ স্পষ্টভাবে পৌঁছায়, কিন্তু কিছুই ফিরে যায় না। টানেলের লগ পরিষ্কার এবং ব্রাউজিং এখনও কাজ করে, তাই টানেল ভুল সন্দেহভাজন। গ্রহণকারী মেশিনে IPv4 সোর্স যাচাই প্যাকেটটি পড়ার আগেই তা ফেলে দেয়।
কোনোকিছু প্যাকেটটি পড়ার আগেই বাদ পড়াটা ঘটে
সোর্স যাচাই প্রতিটি অন্তর্গামী প্যাকেট সম্পর্কে একটি প্রশ্ন করে: এই হোস্ট যদি ওই সোর্সের উত্তর দিত, তবে উত্তরটি কি সেই ইন্টারফেস দিয়েই বেরোত যেটি দিয়ে প্যাকেটটি এইমাত্র এসেছে? উত্তর না হলে কার্নেল প্যাকেটটি আসার সাথে সাথেই ফেলে দেয়। কোনো সকেট বা ফরওয়ার্ডিং পথ এটি কখনও দেখে না, তাই টানেলে করা ক্যাপচার এখনও এমন একটি অনুরোধ লিপিবদ্ধ করে যা অ্যাপ্লিকেশন কখনও পায় না।
এখানে ক্লায়েন্ট তার টানেলে 10.66.0.9 ধরে রাখে, আর OpenVPN সার্ভার অফিস প্রিফিক্সের ভিতরে 192.168.80.10 থেকে উত্তর দেয়। 192.168.80.25-এ থাকা সহকর্মী টানেল ঠিকানায় পিং করেন, তাই অনুরোধটি লোকাল নেটওয়ার্ক পেরোয়, সার্ভার এটিকে টানেলে পাঠায়, এবং এটি অফিসের সোর্স ঠিকানা বহন করে ক্লায়েন্টের টানেল ইন্টারফেসে পৌঁছায়। ওই মেশিনের রাউটিং টেবিলে অফিস প্রিফিক্সটি ইথারনেট ডিভাইসের, টানেলের নয়। যাচাই আগমনের ইন্টারফেসের সাথে রাউটের তুলনা করে, অমিল পায় এবং প্যাকেটটি বাতিল করে, তাই সহকর্মী সম্পূর্ণ ক্ষতি দেখেন যখন দুই প্রান্তই সুস্থ টানেলের কথা বলে।
আয়নার দিকটিরও একই রূপ: ক্লায়েন্ট যখন অফিসের দিকে শুরু করে, তখন একই কারণে অফিসের দিকে উত্তর বাতিল হতে পারে। কেবল এক দিকে যাচাই করা সমাধান সাধারণত দ্বিতীয় টিকিট হিসেবে ফিরে আসে।
কোনো sysctl স্পর্শ করার আগে কার্যকর মোড প্রমাণ করুন
ডিস্ট্রিবিউশনের ডিফল্টে ভরসা না করে কার্যকর মানগুলো পড়ুন, কারণ প্রতি-ইন্টারফেস সেটিং সিদ্ধান্তের অর্ধেক মাত্র। কার্যকর মোড হলো ইন্টারফেস মান ও all মানের মধ্যে বড়টি, তাই টানেল ইন্টারফেসে শূন্য থাকার কোনো অর্থ নেই যখন all এক। কঠোর মোডের সিদ্ধান্ত একটি রাউটিং সিদ্ধান্ত, তাই কার্নেল যে লুকআপ চালায় সেটিই চালান এবং তার উত্তর প্যাকেটটি সত্যিই যে ইন্টারফেসে এসেছে তার সাথে মেলান।
tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filterতারপর ত্রুটি কাউন্টার দেখতে দেখতে পিংটি আবার করুন। ক্যাপচার ইতিমধ্যে যে অনুরোধ দেখায় তার পাশে বাড়তে থাকা সংখ্যাই এই বাদের স্বাক্ষর, অনুপস্থিত রাউটের নয়। সেখানে থাকার সময় মার্সিয়ান প্যাকেট লগিং চালু করুন, যাতে কার্নেল যে সোর্স ও ইন্টারফেস প্রত্যাখ্যান করেছে তার নাম বলে। একসাথে তারা সাইফার, ফায়ারওয়াল এবং অনুপস্থিত iroute-কে ব্যাখ্যা হিসেবে বাদ দেয়।
কিছু বদলানোর আগে বেসলাইন লিখে রাখুন: দুটি মান, লুকআপ যে ডিভাইস বেছেছে, এবং যে কাউন্টার আপনি দেখছিলেন। পরবর্তীতে পরিবর্তনটি আপনার ধারণামতো কাজ করেছে কি না তা এই রেকর্ডই বলে দেয়।
প্রতিটি rp_filter মোড আসলে কী গ্রহণ করে
কার্নেল প্রতি ইন্টারফেসে তিনটি মান দেয়, এবং এগুলো একই নিয়মের তিনটি আভা নয়। শূন্য যাচাই বন্ধ করে। এক হলো কঠোর, যা চায় সোর্সটি আগমনের ইন্টারফেস দিয়েই ফিরে রাউট হোক। দুই হলো শিথিল, যা কেবল চায় টেবিলে সোর্সের কোনো রাউট থাকুক, সেটি যেদিকেই নির্দেশ করুক।
| Value | Name | Accepts | Still rejects |
|---|---|---|---|
| 0 | off | any source at all | nothing on this check |
| 1 | strict | a source routed back out the arrival interface | a source whose route points elsewhere |
| 2 | loose | a source with any route in the table | a source with no route at all |
এখানে গুরুত্বপূর্ণ সারিটি শিথিল, এবং এটি যা বাতিল করতেই থাকে। আপনার টেবিলে যেকোনো জায়গায় রাউটযোগ্য জাল সোর্স পার হয়ে যায়, অথচ কোনো রাউটই নেই এমন সোর্স এখনও প্রত্যাখ্যাত হয়। ল্যাপটপে এটি সংকীর্ণ ছাড়; অন্যের ট্রাফিক ফরওয়ার্ড করা রাউটারে এটি বিস্তৃত ছাড়। মোডটি হোস্টের, তাই একই সংখ্যা দুই জায়গায় ভিন্ন ওজন বহন করে।
এই টপোলজির কোন সারি দরকার তা অভ্যাস থেকে নয়, টেবিল থেকেই আসে। প্যাকেটটি বৈধ এবং এর সোর্স রাউটযোগ্য, তাই শিথিল এটি গ্রহণ করে আর কঠোর করে না। মামলায় কিছুই শূন্য দাবি করে না, আর শূন্য বাছলে এমন যাচাই সরানো হয় যা এখানে কিছুই খরচ করে না।
অস্পষ্টতা দূর করে এমন ক্ষুদ্রতম পরিবর্তন বাছুন
শিথিল মোডই মানানসই ক্ষুদ্রতম পরিবর্তন, এবং এটি নিরীহ সুইচ নয়, কঠোরতার সত্যিকারের হ্রাস। টপোলজি অনুমতি দিলে আরও ভালো বিকল্প আছে: ওভারল্যাপ সরান, অস্পষ্টতা মিলিয়ে যায়।
যেখানে অফিস প্রিফিক্স কেবল ইথারনেটে দরকার, প্রোফাইল যে রাউটগুলো টানে সেখান থেকে এটি বাদ দিন, ঠিকানাটি এক পথে পৌঁছযোগ্য হয়ে যায়। যখন দুই পথ সত্যিই একসাথে থাকতেই হবে, তখন প্রতিটি ইন্টারফেসে যাচাই শিথিল করার বদলে পলিসি রুল দিয়ে সোর্স ও ডিভাইস পিন করুন। এতে মেশিনের বাকি সবকিছুর জন্য কঠোর ফিল্টারিং থাকে এবং ব্যতিক্রমটি সেখানে নথিভুক্ত হয় যেখানে পরের প্রকৌশলী তা খুঁজবেন।
যে পথই নিন, এটি লাইভ কমান্ডে নয়, sysctl drop-in-এ লিখুন। all ও default কী দুটি একসাথে সেট করুন, যাতে পুনঃসংযোগ কঠোর মোড চুপচাপ ফিরিয়ে আনতে না পারে।
# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --systemশিথিল মোড কী হারায়, আর কোথায়
শিথিল মোড এমন সোর্স এখনও প্রত্যাখ্যান করে যেখানে কোনো রাউট পৌঁছাতে পারত না, আর হঠাৎ রাউটযোগ্য জাল সোর্স প্রত্যাখ্যান করা বন্ধ করে। ল্যাপটপে এটি সংকীর্ণ ছাড়। যে ডিভাইস নিজের নয় এমন ট্রাফিক ফরওয়ার্ড করে, সেখানে একই বাছাই অনেক বেশি বিস্তৃত। তাই একই সেটিং কোথায় চলছে তার উপর নির্ভর করে দুটি খুব ভিন্ন অর্থ বহন করে।
অন্যের ট্রাফিক ফরওয়ার্ড করা হোস্টে যাচাই সম্পূর্ণ বন্ধ করা একমাত্র সংস্কার যা এড়ানো উচিত। শূন্য সেই যাচাই ফেলে দেয় যা শিথিল মোড সযত্নে রাখে। হোস্ট যদি অন্যের জন্য ফরওয়ার্ড করে, তবে বরং আগের বিভাগের পলিসি রুল বিকল্পের পক্ষে যুক্তি দিন।
একটি নোট রেখে দিন যেখানে দুটি ইন্টারফেস, ওভারল্যাপিং প্রিফিক্স এবং এখন সফল হওয়া নির্দিষ্ট প্রোবের নাম থাকে। ফিল্টারিং সমন্বয় করা হয়েছে বলে একটি লাইনের চেয়ে এটি পরের প্রকৌশলীর জন্য বেশি কাজে লাগে।