সাইট-থেকে-সাইট VPN: কোন দিকে আসলে একটি নিয়ম দরকার?

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

স্টেটফুল ফিরতি ট্র্যাফিক সংখ্যা বদলায়

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

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

ফায়ারওয়াল কোথায় ডিক্রিপ্ট করা প্যাকেট দেখে

নীতি-ভিত্তিক টানেলে ফায়ারওয়াল ডিক্রিপশনের আগে এনক্রিপ্ট করা প্যাকেট এবং পরে ডিক্রিপ্ট করা প্যাকেট, ভিন্ন ইন্টারফেসে মূল্যায়ন করতে পারে। ভুল ইন্টারফেসের জন্য লেখা নিয়ম উপস্থিত, সঠিক এবং কখনও মেলে না। এভাবেই কাজ করা স্থাপনা থেকে অনুলিপি করা নিয়ম-সমষ্টি অভিন্ন হার্ডওয়্যারে ব্যর্থ হতে পারে।

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

অপ্রতিসম রাউটিং অনুমানটি ভেঙে দেয়

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

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

প্রকৃত সোর্স ঠিকানা দিয়ে দুই দিক যাচাই করুন

দূরের পক্ষ যে ঠিকানা সত্যিই দেখে তা দিয়ে পরীক্ষা করুন, কারণ অনুবাদ সোর্স নিয়মকে কিছুর সঙ্গেই মেলাতে না পারে। একই সময়ে দুই গেটওয়েতে ক্যাপচার চালান।

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

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

অনুবাদের পর সোর্স ঠিকানা, ডিক্রিপ্ট করা প্যাকেট যে ইন্টারফেস ব্যবহার করেছে এবং যে নিয়ম মিলেছে তা লিখে রাখুন। এই তিনটি তথ্য পুরো তদন্ত না পুনরাবৃত্তি করেই পরের টিকিটের উত্তর দেয়।