ভার্চুয়াল pfSense TAP ব্রিজ: ফ্রেম মরে যেতে পারে এমন তিনটি স্থান
ব্রিজ, তার সদস্য এবং ভার্চুয়াল সুইচ প্রত্যেকে আলাদাভাবে সিদ্ধান্ত নেয়। যে নিয়ন্ত্রণ কখনোই পথে ছিল না তা নিষ্ক্রিয় করার আগে খুঁজে বের করুন কোন মালিক ফিল্টার করেছে।
আপনি LAN ইন্টারফেসে একটি নিয়ম নিষ্ক্রিয় করেন, ফ্রেম তবুও অদৃশ্য হয়, আর সিদ্ধান্তে পৌঁছান যে pfSense নিজের ফায়ারওয়াল উপেক্ষা করছে। সাধারণত যা ঘটেছে তা হলো অন্য মালিক সিদ্ধান্তটি নিয়েছে: ব্রিজ নিজেই, সদস্য ইন্টারফেস, অথবা গেস্টের বাইরের ভার্চুয়াল সুইচ। প্রত্যেকের নিজস্ব নিয়ন্ত্রণ ও নিজস্ব লগ আছে।
নিচের তিনটি সীমানা কোনো সেটিং বদলানোর আগে আলাদা করা উচিত, কারণ একটি নিষ্ক্রিয় করা অন্যটির ক্ষতিপূরণ দিতে পারে না।
একটি ফ্রেম, তিন নীতি-মালিক
TAP ক্লায়েন্টের একটি ফ্রেম টানেল ডিভাইস দিয়ে ঢোকে, pfSense ব্রিজ পার হয়, LAN সদস্য দিয়ে বের হয়, এবং কিছুতে পৌঁছানোর আগে একটি ভার্চুয়াল সুইচ অতিক্রম করে। গেস্টের ভিতরে ফিল্টারিং ব্রিজে বা সদস্য ইন্টারফেসে ঘটতে পারে, এবং কোনটি সক্রিয় তা নির্দিষ্ট বৈশিষ্ট্য নয়, বরং কনফিগারেশনের পছন্দ। গেস্টের বাইরে হাইপারভাইজার স্থির করে সেই ভার্চুয়াল অ্যাডাপ্টর নিজের নয় এমন উৎস MAC দিয়ে ফ্রেম পাঠাতে পারবে কি না। সেই যেকোনো বিন্দুতে ড্রপ ক্লায়েন্টের দিক থেকে একই রকম দেখায়।
তদন্ত শুরু করার আগে অভীষ্ট পথটি লিখে রাখুন: টানেল সদস্য, ব্রিজ, LAN সদস্য, ভার্চুয়াল সুইচ, গন্তব্য। তারপর জিজ্ঞাসা করুন সেই পথে কোন মালিক ফ্রেমটি দেখতে পেতেন।
কোন pfSense নিয়ন্ত্রণ ফিল্টার করছে
pfSense এটির জন্য দুটি sysctl নথিভুক্ত করে — একটি ব্রিজ সদস্যদের উপর ফিল্টারিংয়ের জন্য, আরেকটি ব্রিজের নিজের উপর ফিল্টারিংয়ের জন্য, এবং অন্তত একটি সক্রিয় থাকতে হবে। ব্রিজ-স্তরের ফিল্টারিং ব্রিজ সদস্যদের মাধ্যমে আসা ট্রাফিকে প্রযোজ্য, তাই এটি অভিমুখে ইনবাউন্ড, প্রতিসম নয়। যে ইন্টারফেস প্রকৃতপক্ষে ফিল্টার করছে তার নিয়মগুলো পড়ুন, কারণ ফিল্টারিং ভূমিকা ছাড়া কোনো সদস্যে লেখা নিয়ম কিছুই করে না। ব্রিজ ফিল্টারিং ডকুমেন্টেশন মালিকানা স্পষ্ট করে।
IP ঠিকানা ছাড়া সদস্য ইন্টারফেসের নিজের কোনো ঠিকানা বা সাবনেট ম্যাক্রো থাকে না, তাই সেই ম্যাক্রোর বিরুদ্ধে লেখা নিয়ম আপনার অভীষ্ট LAN ছাড়া অন্য কিছু বর্ণনা করতে পারে। সুবিধার ম্যাক্রোর বদলে ইচ্ছাকৃতভাবে নির্ধারিত নেটওয়ার্ক অবজেক্ট ব্যবহার করুন।
ফ্র্যাগমেন্ট ফ্রেম নয়
ইথারনেট ফ্রেম IP প্যাকেট বহন করে, এবং একটি IP প্যাকেট বড় ডেটাগ্রামের ফ্র্যাগমেন্ট হতে পারে, তাই দুটি শব্দ বিনিময়যোগ্য নয়। টানেলের ভিতরে একটি ভিতরের প্যাকেট এবং তার বাইরে একটি বাইরের ট্রান্সপোর্ট প্যাকেটও থাকে, আর ব্যর্থতা যেকোনোটির হতে পারে। ছোট একটি ping সেই স্ট্যাকের মধ্য দিয়ে একটি পথ পরীক্ষা করে এবং বড় ট্রান্সফার সম্পর্কে কিছুই প্রমাণ করে না। দুটি সংলগ্ন সীমানায় ব্যর্থ বিনিময় তুলনা করুন এবং কোনো নিয়মকে দোষ দেওয়ার আগে ড্রপের কারণ পড়ুন।
ফ্র্যাগমেন্ট অদৃশ্য হলে উত্তর হলো সীমিত সংশোধন বা প্যাকেটের আকার নিয়ে তদন্ত, ফিল্টারিং পুরোপুরি নিষ্ক্রিয় করার সিদ্ধান্ত নয়।
হাইপারভাইজারের নিজস্ব প্রবেশ-সিদ্ধান্ত আছে
অন্য মেশিনের জন্য ট্রাফিক ব্রিজ করা একটি গেস্ট এমন ফ্রেম নির্গত করে যাদের উৎস MAC ঠিকানা তার নিজের অ্যাডাপ্টরের নয়, এবং অনেক ভার্চুয়াল সুইচ পোর্ট গ্রুপ অনুমতি না দিলে এটিকে স্পুফিং মনে করে। সেই ট্রান্সমিশন অনুমোদন করা এবং অ্যাডাপ্টরকে প্রতিটি ফ্রেম গ্রহণের অনুমতি দেওয়া আলাদা নিয়ন্ত্রণ, এবং সর্বত্র দুটোই সক্রিয় করা সমস্যার প্রয়োজনের চেয়ে অনেক বড় পরিবর্তন। ব্রিজকে কোন ফ্রেম গ্রহণ করতে হবে ও কোন ফ্রেম নির্গত করতে হবে তা নির্ধারণ করুন, তারপর কেবল সেই আচরণ তার মালিকানা আছে এমন সীমানায় দিন। দূর থেকে পরিচালিত ব্রিজ পরিবর্তনের আগে কনসোল অ্যাক্সেস রাখুন।
সংযোগ পুনরুদ্ধার পরীক্ষার অর্ধেক; বাকি অর্ধেক হলো নিশ্চিত করা যে যে প্রবাহ অবরুদ্ধ থাকা উচিত তা এখনও অবরুদ্ধ আছে।
কোন মালিক ফিল্টার করেছে, কোন নিয়ন্ত্রণ বদলেছে এবং কোন দুটি প্রবাহ আপনি যাচাই করেছেন তা লিখে রাখুন। সেই রেকর্ড পরবর্তী ঘটনাটিকে pfSense নিজেকে উপেক্ষা করছে এই একই অনুমান দিয়ে শুরু হতে দেয় না।