VPN গেটওয়ের IP ফরওয়ার্ডিং দরকার: কী যাচাই করবেন

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

দুটি ভূমিকা স্বাধীন, এবং দুটি ঠিকানা পরিবারও।

নিজের ঠিকানায় উত্তর দেওয়া কিছুই প্রমাণ করে না

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

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

একই কথা ফরওয়ার্ডিং সিদ্ধান্তের সামনের ফায়ারওয়ালের ক্ষেত্রেও প্রযোজ্য, যার কী ফরওয়ার্ড করা যাবে সে বিষয়ে নিজস্ব নীতি আছে।

প্রতিটি ঠিকানা পরিবার আলাদাভাবে যাচাই করুন

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

ফরওয়ার্ডিং চারটি শর্তের একটি

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

ক্লাউড প্ল্যাটফর্ম একটি পঞ্চম বিবেচনা যোগ করে। কিছু ইনস্ট্যান্সে সোর্স ও গন্তব্য যাচাই প্রয়োগ করে, যা গেস্ট কার্নেল কী করার জন্য কনফিগার করা আছে তা নির্বিশেষে ফরওয়ার্ডেড প্যাকেট ফেলে দেয়। সেখানে প্ল্যাটফর্মের নিজস্ব নেটওয়ার্কিং ডকুমেন্টেশনই কর্তৃত্ব, VM-এর ভেতরের sysctl আউটপুট নয়।

ক্লায়েন্ট থেকে পরীক্ষা করুন, গেটওয়ে থেকে নয়

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

লিসেনার নিয়ম ও ফরওয়ার্ডিং নিয়ম আপনার মাথায় এবং পরিবর্তন রেকর্ডে আলাদা রাখুন। VPN পোর্ট খোলা ক্লায়েন্টদের সার্ভিসে প্রবেশ করতে দেয়; এটি তাদের পেছনের নেটওয়ার্কে কিছুই দেয় না, আর বছরের পর বছর বেড়ে ওঠা ফায়ারওয়াল তালিকায় দুটিই একই রকম দেখায়।

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