VPN গেটওয়ে পুনরায় চালু হওয়ার পরেও IPv4 ফরওয়ার্ডিং টিকে থাকুক

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

গেটওয়েতে পৌঁছানো ফরওয়ার্ডিংয়ের সমান নয়

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

লিখুন যে ক্লায়েন্ট প্যাকেট কোন ইন্টারফেসে আসে এবং পরের পথ কোন ইন্টারফেস দিয়ে বেরোয়। দুটোই একই নেমস্পেসের অন্তর্গত, এবং গুরুত্বপূর্ণ সেটিংটি সেই নেমস্পেসেই আছে।

মানটি সেখানেই পড়ুন যেখানে প্যাকেট সত্যিই আছে

হোস্ট নেমস্পেসে রাউট করা গেটওয়েতে, একটি নির্দেশই প্রশ্নের উত্তর দেয়: sysctl net.ipv4.ip_forward। যখন ইনগ্রেস এবং পরের পথ একটি নামযুক্ত নেমস্পেসে থাকে, সেই নেমস্পেসকেই জিজ্ঞাসা করুন: ip netns exec vpn-gw sysctl net.ipv4.ip_forward। হোস্টের মান নেমস্পেসের মানের বিকল্প নয়, এবং হোস্টে এক থাকা কোনো কিছুর প্রমাণ নয়।

প্রতিটি রাউটিং প্রসঙ্গে এমন লেবেল থাকে না যা আপনি ip netns-কে দিতে পারেন। কন্টেইনার রানটাইম এবং সেবাগুলো এমন নেমস্পেস তৈরি করে যেগুলো কখনো বন্ধুত্বপূর্ণ নামে নিবন্ধিত হয় না, এবং সেগুলোর জন্য আপনি রানটাইমের পরিদর্শন সরঞ্জাম ব্যবহার করেন। vpn-gw-এর জায়গায় আসল নাম বা একই প্রসঙ্গে পৌঁছানো রানটাইম ব্যবস্থা রাখুন, এবং হোস্ট স্তরে অনুমান করা বন্ধ করুন।

সেটিংটিকে একজন মালিক দিন

প্রচলিত systemd হোস্ট গেটওয়েতে, টেকসই রূপ হলো প্রশাসকের বেছে নেওয়া নামের drop-in ফাইল, যেমন /etc/sysctl.d/60-vpn-forwarding.conf, যাতে net.ipv4.ip_forward = 1 থাকে। ফাইলটি লিখুন, তারপর জীবন্ত অবস্থাও বদলাতে যেন ওই নির্দিষ্ট ফাইলটিই লোড করুন: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, এবং পরে ফিরে পড়ে যাচাই করুন। ফাইলের নাম একটি উদাহরণ, সংরক্ষিত VPN পথ নয়, এবং শুরুর সংখ্যাটি গুরুত্বপূর্ণ কারণ পরে সাজানো ফাইলগুলো জেতে।

অগ্রাধিকার হলো সেই জায়গা যেখানে টেকসইতা নিঃশব্দে ভাঙে। বিতরণের লোডার এবং আপনার নিজের drop-in দুটোই পরীক্ষা করুন, কারণ procps sysctl --system শেষে /etc/sysctl.conf-ও পড়ে, অথচ systemd-এর sysctl.d ক্রম সম্পূর্ণ ভিন্ন একটি ক্রম। পরের বরাদ্দ একই কী সাথে সাথে ফিরিয়ে দিতে পারে, ফলে আপনার ফাইল সঠিক কিন্তু কার্যকর মান ভুল থাকে। সেই তর্ক জিততে বিদ্যমান প্রশাসক ফাইল পুনঃলিখন করবেন না; মালিক খুঁজে সেখানেই বদলান।

বুটের পরে তৈরি নেমস্পেস হোস্ট drop-in দ্বারা একেবারেই নিয়ন্ত্রিত হয় না। তার সেটিং যেটি এটি তৈরি করে তারই, তা কন্টেইনার রানটাইম হোক বা নেমস্পেসের প্রভিশনিং ইউনিট। প্রশ্ন এড়াতে কন্টেইনারকে বিস্তৃত হোস্ট সুবিধা দেওয়া সঠিক মালিক চিহ্নিত করতে দশ মিনিট ব্যয় করার চেয়েও খারাপ লেনদেন।

সুইচ ঘোরানোর আগে তার খরচ জানুন

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

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

টেকসইতা প্রমাণ করুন, তারপর পথের বাকি অংশ পরীক্ষা করুন

চারটি মুহূর্তে মানটি ফিরে পড়ুন: পরিবর্তনের ঠিক পরে, VPN ইন্টারফেস দেখা দেওয়ার পরে, আবার সংযোগের পরে, এবং পরিকল্পিত পুনরায় চালুর পরে। এই যেকোনো বিন্দুতে ফিরে যাওয়া মানের দ্বিতীয় মালিক থাকে, এবং আরেকবার এককালীন লেখা তা পরের রিবুট পর্যন্তই লুকায়।

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

drop-in পথ, নেমস্পেসের মালিক এবং ফিরে পড়ার নির্দেশ runbook-এ একসাথে রাখুন। পরবর্তীতে এটি যে নেবে তাকে মান পড়তে, কে মালিক দেখতে, এবং সমস্যাটি টেকসইতার নাকি পথের বাকি অংশের তা এক মিনিটে সিদ্ধান্ত নিতে পারতে হবে।