রাউটেড বা ব্রিজড VPN: ক্লায়েন্টকে যা পৌঁছাতে হবে তার ভিত্তিতে বেছে নিন

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

টিকিট ডেস্কে একই রকম দেখতে দুটি অনুরোধ

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

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

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

রাউট LAN সদস্যপদের চেয়ে সংকীর্ণ

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

রাউটকে অনুমতির সঙ্গে গুলিয়ে ফেলবেন না। ক্লায়েন্টকে একটি সাবনেটে পৌঁছানোর পথ বলা তাকে অন্য গন্তব্য চেষ্টা করা থেকে থামায় না।

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

ব্রিজ ভর্তির প্রশ্নটি বদলে দেয়

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

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

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

ফিল্টারিং উভয় টপোলজিতেই আছে

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

সীমানার প্রতিশ্রুতি দেওয়ার আগে প্ল্যাটফর্মটি আসলে কী সমর্থন করে তা যাচাই করুন:

bridge link show
nft list ruleset

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

তিনটি প্রচেষ্টায় সীমানা প্রমাণ করুন

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

একই ক্লায়েন্ট থেকে অনুমোদিত ও অস্বীকৃত পথ দুটোই চালান, আর দুটোই লিপিবদ্ধ করুন:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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