একটি VLAN-এর জন্য TAP ব্রিজ: সাবইন্টারফেস সংযুক্ত করুন

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

একটি VLAN সম্প্রসারণ মানে layer-2 ডোমেন একটি, এবং ব্রিজকে সবগুলো বহনকারী ট্রাঙ্কে নয়, সেই ডোমেনেই যোগ দিতে হবে।

ট্যাগ দেখা যায় না, কারণ আপনি ট্রাঙ্ক ব্রিজ করেছেন

VLAN 120 বহনকারী একটি Linux আপলিংক eno1 একটি ম্যানেজড সুইচের দিকে নিন। একক VLAN-এর জন্য যে ডিজাইন কাজ করে তা হল tap_vpn কে br_vpn-এ ব্রিজ করা, যেখানে br_vpn-এ eno1 নয় বরং eno1.120 থাকে। VLAN সাবইন্টারফেস ইগ্রেসে ট্যাগ প্রয়োগ করে এবং ইনগ্রেসে তা সরিয়ে দেয়, তাই ব্রিজ ওই এক VLAN-এর জন্য কেবল আনট্যাগড ফ্রেমই দেখে। এর বদলে ফিজিক্যাল ইন্টারফেস ব্রিজে রাখুন, তাহলে একই ফ্রেম ট্রাঙ্ক পোর্টে আনট্যাগড হয়ে বেরোবে, যা আপনি পরিকল্পনা করেননি।

VLAN ফিল্টারিং বন্ধ রেখে ট্রাঙ্ক ব্রিজ করা একই ফলাফলের শর্টকাট নয়। এটি ওই তারের প্রতিটি VLAN ব্রিজকে দিয়ে দেয়, যেগুলো ক্লায়েন্টদের দেখা উচিত নয় সেগুলোসহ।

দুটি বৈধ ডিজাইন, ট্যাগের মালিক একজন

VLAN-সচেতন ব্রিজ হল অন্য বৈধ বিন্যাস: ট্রাঙ্ক একটি ব্রিজ পোর্টে ঢোকে, আর প্রতি-পোর্ট সদস্যপদ, PVID ও ট্যাগড ইগ্রেস সেটিংস ঠিক করে কোন VLAN গুলো যাবে। সেখানে ট্যাগিংয়ের মালিক ব্রিজ, আর তার নিচে VLAN সাবইন্টারফেস যোগ করলে এক কাজের জন্য দ্বিতীয় মালিক বসে যাবে। দুটি ডিজাইনই কাজ করে; দুটির মিশ্রণ করে না। কোনো সদস্য তালিকা সম্পাদনার আগে ঠিক করুন কোন বস্তু ট্যাগ প্রয়োগ করবে।

আপনি যে ডিজাইনই বাছুন, সুইচ পোর্টকে তার সঙ্গে মিলতে হবে। VLAN আনট্যাগড বহনকারী অ্যাক্সেস পোর্ট ফিজিক্যাল ইন্টারফেসকে সংযুক্তি হিসেবে পায়, আর ট্রাঙ্ক পোর্ট পায় ট্যাগড সাবইন্টারফেস। অনুপযুক্ত অ্যাক্সেস পোর্টে সাবইন্টারফেস যোগ করলে কিছুই সারায় না।

সদস্যপদের সঙ্গে ঠিকানাটি সরান

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

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

ক্লায়েন্ট অ্যাড্রেসিংও একই যত্ন চায়। ব্রিজকৃত VPN ক্লায়েন্টদের সম্প্রসারিত সাবনেটে রাখে, তাই পুল অন্য লিজ বা স্ট্যাটিক বণ্টনের সঙ্গে ওভারল্যাপ করা চলবে না, আর DHCP-পরিবেশিত বিন্যাসটিকেই LAN সত্যিই প্রত্যাশা করে এমন হতে হবে। কাজ করা layer-2 পথ ডুপ্লিকেট ঠিকানা সম্পর্কে কিছুই বলে না।

রুটকে দোষারোপের আগে সদস্যপদ যাচাই করুন

উদ্দিষ্ট অবস্থা নয়, বর্তমান অবস্থা পড়ুন: ip -d link show dev eno1.120 VLAN id ও তার প্যারেন্ট ছাপে, ip link show master br_vpn ব্রিজের সদস্যদের তালিকা দেয়, আর bridge vlan show প্রতি-পোর্ট সদস্যপদ ও ইগ্রেস আচরণ জানায়। সাবইন্টারফেস ডিজাইনে নিশ্চিত করুন যে TAP ডিভাইস ও VLAN ডিভাইসই সদস্য। VLAN-সচেতন ব্রিজে পোর্ট নীতিটাই দেখুন, কারণ ব্রিজ থাকা মানেই এটি কী অনুমোদন করে তার প্রমাণ নয়।

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