কেন একটি শেয়ার করা TAP VPN-এর এখনও পোর্টালে HTTPS দরকার
একটি TAP VPN পিয়ারকে প্রমাণ করে, তার পিছনের সেবাকে নয়। পোর্টালে হোস্টনেম যাচাই রাখুন এবং যে প্রতিবেশীদের আপনি বিশ্বাস করেন না তাদের আলাদা করুন।
দুটি ডিভাইসের বৈধ VPN শংসাপত্র আছে এবং তারা একটি ব্রিজ করা ইথারনেট সেগমেন্ট শেয়ার করে। তাদের মধ্যে কেবল একটিরই অফিস পোর্টালের উত্তর দেওয়ার কথা, আর অন্যটি এখনও সেই সেগমেন্টে পোর্টালের ঠিকানা দাবি করতে পারে। টানেল তার কাজ করেছে: এটি উভয় পিয়ারকে প্রমাণ করেছে এবং সার্ভারের প্রতিটি পথ এনক্রিপ্ট করেছে। যা করেনি তা হলো কোনটি একটি সেবার নামের মালিক তা প্রত্যয়ন করা, আর এই ফাঁকই পোর্টালের এখনও একটি বৈধ সার্টিফিকেট প্রয়োজন হওয়ার কারণ।
VPN আসলে কী প্রমাণ করে
একটি VPN হ্যান্ডশেক একটি প্রশ্নের উত্তর দেয়: কোন পিয়ার কোন কী উপাদান দিয়ে এই টানেল সম্পূর্ণ করেছে। সেই উত্তর প্রতি পিয়ার ও প্রতি সংযোগের জন্য আলাদা, এবং পিয়ার পরে যে সেবাগুলো প্রকাশ করে সে সম্পর্কে কিছুই বলে না। TAP সেগমেন্টে পিয়ার এমনকি একটিমাত্র ঠিকানাও নয়, কারণ সে ব্রিজ যে-কোনো MAC এবং যে-কোনো IP শিখতে রাজি তা উপস্থাপন করতে পারে। প্রমাণীকরণ টানেলের প্রান্তে থামে, অ্যাপ্লিকেশনে নয়।
তিনটি প্রশ্নকে একত্রে মিলিয়ে না দিয়ে আলাদা করুন। প্রতিটির নিজস্ব প্রক্রিয়া ও নিজস্ব ব্যর্থতার ধরন আছে।
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
একটি স্থাপনায় পুরোপুরি প্রমাণিত টানেল এবং তার পিছনে সম্পূর্ণ অপ্রমাণিত সেবা থাকতে পারে। এমন হোস্টেও যাচাই করা সার্টিফিকেট থাকতে পারে যার দ্বিতীয় স্তরের ঠিকানা অন্য একটি পিয়ার দাবি করছে, তাই ডিজাইনে একটির বদলে অন্যটি নয়, উভয় নিয়ন্ত্রণই থাকা উচিত। সারণিটি তিনটি সারিতে পুরো যুক্তি।
শেয়ার করা সেগমেন্টে ARP কোনো ডিরেক্টরি নয়
ARP স্থানীয় লিঙ্কে একটি IPv4 ঠিকানাকে MAC-এর সাথে মেলায় এবং সেই লিঙ্কের যে-কেউ পাঠানো উত্তর গ্রহণ করে। একটি উদার ব্রিজ করা সেগমেন্টে একটি পিয়ার অন্য ডিভাইসের ঠিকানা দাবি করতে পারে, আর ব্রিজ ফ্রেমগুলো সেই দিকে পাঠায় যে সবশেষে উত্তর দিয়েছে। সার্ভারের প্রতি প্রতিটি ক্লায়েন্ট পথ এনক্রিপ্ট করলে তা বদলায় না, কারণ ফ্রেম ব্রিজে পৌঁছানোর আগেই ডিক্রিপ্ট হয়। ARP-এর বিশ্বাসের সীমা সেগমেন্ট, টানেল নয়।
হোস্ট আসলে কী শিখেছে তা দেখুন: ip neigh show বর্তমান ম্যাপিং ও তাদের অবস্থা তালিকাভুক্ত করে, আর স্বাভাবিক পরিচালনার সময় দুই MAC ঠিকানার মধ্যে বদলে যাওয়া এন্ট্রি উপেক্ষা করার বদলে তদন্তযোগ্য লক্ষণ। সুস্থ ছোট সেগমেন্টে এসব এন্ট্রি দীর্ঘ সময় স্থির থাকে।
পিয়ার বিচ্ছিন্নকরণ ও ব্রিজ নীতি ঠিক এই পরিস্থিতির জন্যই আছে। সেবা কেবল IP হলে এবং ডিভাইসগুলোর একে অপরের ফ্রেম দেখার কোনো কারণ না থাকলে রাউটেড ডিজাইন সাধারণত ভালো উত্তর।
সার্টিফিকেট যাচাই সেবার কাছেই রাখুন
অ্যাপ্লিকেশন TLS সেই প্রশ্নের উত্তর দেয় যা টানেল দিতে পারে না: আমি কি এই সেবাতেই পৌঁছাতে চেয়েছিলাম. ব্রাউজার সার্টিফিকেটের সাথে হোস্টনেম মেলায়, আর শৃঙ্খলের যে অংশটি পিয়ারের বদলে পোর্টালের নাম বলে সেটি কেবল এই যাচাই।
সতর্কতাটিকে কেবল চেহারার বিষয় ভাবার আগে সার্ভার কী উপস্থাপন করে তা দেখুন। openssl s_client -connect portal.example.internal:443 -servername portal.example.internal শৃঙ্খল ও সাবজেক্ট অল্টারনেটিভ নাম ছাপে। আপনি যে নাম লিখেছেন তা ওই তালিকায় না থাকলে সতর্কতাটি সঠিক এবং সার্টিফিকেটই ঠিক করার বিষয়। ব্যবহারকারীদের এটি এড়িয়ে যেতে শেখানো একটি কাজ করা নিয়ন্ত্রণকে সাজসজ্জায় পরিণত করে।
OpenVPN ব্রিজিং নির্দেশিকা ইথারনেট মডেল এবং তার চারপাশের নীতি বিকল্পগুলো বর্ণনা করে, আর সেগমেন্ট কী অনুমোদন করার কথা তার সঠিক তথ্যসূত্র এটি। ব্রিজের নিয়ম শিথিল করার আগে এটি পড়ুন, কারণ এটি যে মডেল বর্ণনা করে উপরের প্রতিটি যাচাই সেটাই ধরে নেয়।
ওই পিয়ারদের আদৌ একটি সেগমেন্ট শেয়ার করা উচিত কি না তা ঠিক করুন
প্রয়োজন কেবল IP পৌঁছানো হলে সবচেয়ে সস্তা সমাধান সাধারণত দ্বিতীয় স্তর শেয়ার করা বন্ধ করা। রাউটেড VPN প্রতিটি ক্লায়েন্টকে নিজের ঠিকানা দেয়, শেয়ার করা ব্রডকাস্ট ডোমেইন সরায় এবং পিয়ার-থেকে-পিয়ার ট্রাফিককে ডিফল্টের বদলে নীতিগত সিদ্ধান্তে পরিণত করে। তখন পোর্টালের রক্ষা করার একটি ঠিকানা থাকে এবং তা দাবি করার মতো প্রতিবেশী থাকে না।
সেগমেন্ট থাকতেই হলে সার্ভার-সাইড সেটিংটি দেখুন যা ক্লায়েন্টদের একে অপরের কাছে পৌঁছাতে দেয়: grep -n client-to-client /etc/openvpn/server.conf. এটি নিষ্ক্রিয় থাকলে ক্লায়েন্ট ট্রাফিক সার্ভার দিয়ে যায় এবং সেখানেই ফিল্টার করা যায়। এটি সক্রিয় থাকলে পিয়াররা সরাসরি ব্রিজ দিয়ে ফ্রেম বিনিময় করে এবং আপনার ফিল্টারিং পয়েন্ট হলো ব্রিজ ও হোস্ট ফায়ারওয়াল।
প্রতিটি হোস্ট আসলে কোন কোন সুরক্ষার উপর নির্ভর করে তা লিখে রাখুন: টানেল প্রমাণীকরণ, সেগমেন্ট বিচ্ছিন্নতা বা অ্যাপ্লিকেশন TLS। যে হোস্ট তিনটির উপরই নির্ভর করে সে ঠিক আছে। আর যে হোস্ট প্রথমটির উপর নির্ভর করে এবং ধরে নেয় বাকি দুটি তার সাথে এসেছে, শেষ পর্যন্ত ভুল বিষয়বস্তু পরিবেশন করে সে-ই।