আপনি net.ipv4.conf.default.forwarding=1 সেট করেছেন, VPN পুনরায় চালু করেছেন, তবুও টানেল এমন প্যাকেট ফেলে দিচ্ছে যা গেটওয়ের রাউট করা উচিত। ফাইলে সেটিংটি ঠিক দেখাচ্ছে, আর ইন্টারফেস এখনও বলছে ফরওয়ার্ডিং বন্ধ। কিছুই ভাঙেনি: আপনি ভবিষ্যতের ইন্টারফেসগুলো যে মান উত্তরাধিকারে পায় সেটি বদলেছেন, চলমান টানেল যে মান ব্যবহার করছে সেটি নয়।

টানেলের মালিক যে হোস্টে, সেখানে টানেল সত্যিই যে নেটওয়ার্ক namespace-এ আছে সেখানে এটি ধাপে ধাপে দেখুন। একটি কন্টেইনার বা নেটওয়ার্ক namespace ইন্টারফেসটি ধরে রাখতে পারে, অথচ হোস্ট ভিন্ন সংখ্যা দেখাতে পারে।

তিনটি মান একসাথে পড়ুন

গেটওয়ে-ব্যাপী সুইচ, নতুন ইন্টারফেসের টেমপ্লেট এবং আপনার আগ্রহের ইন্টারফেস — এই তিনটি তুলনা করে শুরু করুন। tun0-এর বদলে প্রকৃত ইনগ্রেস ইন্টারফেস বসান, এবং ফেরত যাওয়ার ইন্টারফেসটিও পড়ুন, কারণ ফরওয়ার্ডিং প্যাকেট যে বিন্দুতে পৌঁছায় সেখানেই মূল্যায়িত হয়।

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

একটি সাধারণ ফলাফল হলো ip_forward = 0, default.forwarding = 1 এবং tun0.forwarding = 0। প্রথম দুটি হোস্টের ভূমিকা নিয়ে একমত নয়, আর তৃতীয়টি দেখায় ইন্টারফেস আসলে কী করছে। এই সমন্বয়টি এমন হোস্টের সাথে মেলে যা কখনও রাউটার হিসেবে কনফিগার হয়নি, শুধু একটি টেমপ্লেট মান পেয়েছে। তিনটি সংখ্যা পরস্পরবিরোধী নয়; তারা তিনটি ভিন্ন প্রশ্নের উত্তর দিচ্ছে। টেমপ্লেট মান লেখাও হোস্টের ভূমিকা নির্ধারণ করে না।

কেন গ্লোবাল নবটিই নড়ে

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

কার্নেল ডকুমেন্টেশন ip_forward-কে একটি সংশ্লিষ্ট কারণে বিশেষ বলে চিহ্নিত করে: এটি বদলালে আরও কিছু IPv4 প্যারামিটার হোস্ট বা রাউটার ডিফল্টে রিসেট হয়। এতে এটি একটি ভোঁতা যন্ত্র হয়ে যায়। গেটওয়ে ভূমিকা প্রতিষ্ঠার অংশ হিসেবে একবার সেট করা ঠিক আছে; ডিবাগিং কৌশল হিসেবে বারবার টগল করলে আপনি যত্ন করে ঠিক করা কনফিগারেশন নিঃশব্দে পুনর্লিখিত হতে পারে।

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

সেটিংটি সঠিক জায়গায় স্থায়ী করুন

একবারের সফল sysctl -w প্রমাণ করে কার্নেল মানটি গ্রহণ করে। এটি রিবুটে টেকে না, এবং পুনঃসংযোগে ইন্টারফেস কনফিগারেশন সম্পর্কে নিজের ধারণা আবার প্রয়োগ করা নেটওয়ার্ক ম্যানেজারেও টেকে না। গেটওয়ে ভূমিকাটি sysctl কনফিগারেশন ফাইলে বা হোস্টের মালিক নেটওয়ার্ক ম্যানেজারে রাখুন, তারপর এটি প্রয়োগ করা সার্ভিসটি পুনরায় চালু করুন।

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

VPN পুনঃসংযোগের পরে এবং আবার রিবুটের পরে একই তিনটি মান আবার পড়ুন। নতুন তৈরি টানেল একটি নতুন ইন্টারফেস, আর নতুন ইন্টারফেস সৃষ্টির সময়ে বলবৎ ডিফল্টটি নেয়। যদি ওই ঘটনাগুলোতে সংখ্যাগুলো বদলায়, তবে কনফিগারেশনটি এমন কিছু প্রয়োগ করছে যা আপনি এখনও চিহ্নিত করেননি।

ভুল যন্ত্র দিয়ে এটি সারাবেন না

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

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

IPv6 কেসটি আলাদা রাখুন

এখানে সবকিছু IPv4। IPv6 ফরওয়ার্ডিং, রাউটার বিজ্ঞাপন এবং accept_ra আচরণের নিজস্ব নিয়ন্ত্রণ আছে, আর ipv4 পথটি ipv6 সেটিংয়ে কপি করলে এমন ফাইল তৈরি হয় যা বিশ্বাসযোগ্য দেখায় কিন্তু দরকারি কিছু করে না। দ্বৈত-স্ট্যাক গেটওয়ের জন্য দুটি সেটই সচেতনভাবে কনফিগার করা দরকার।

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

সম্পর্কিত নিবন্ধ