মূল কন্টেন্টে যান
লাইফ সিকিউরিটি

সাইটে অনুসন্ধান

পেজ ও বিভাগ খুঁজুন।

যোগাযোগ নেটওয়ার্কের ধরন

সর্বশেষ হালনাগাদ:

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

মেসেজিংয়ে সাধারণ ৪টি ডিজাইন রয়েছে: সেন্ট্রালাইজড (Centralized), ফেডারেটেড (Federated), পিয়ার-টু-পিয়ার (Peer-to-peer), এবং ইউজার অ্যাকাউন্ট এড়ানোর জন্য তৈরি করা রিলে নেটওয়ার্ক (Relay networks)। এগুলোর প্রতিটি ভিন্ন ভিন্ন পক্ষের ওপর নির্ভর করে এবং ভিন্ন ভিন্ন উপায়ে ব্যর্থ হয়। এই পেজটি পড়ার পর আপনি জানতে পারবেন প্রতিটি ডিজাইন কী কী প্রকাশ করে দেয়, কেন “বিকেন্দ্রীভূত বা ডিসেন্ট্রালাইজড” মানেই “প্রাইভেট” নয়, এবং আপনার আসল ঝুঁকির ওপর ভিত্তি করে কীভাবে সঠিক মাধ্যমটি বেছে নেবেন।

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

সহজ কথায় যোগাযোগ নেটওয়ার্ক কী

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

সেন্ট্রালাইজেশন নিয়ে ইন্টারনেট প্রকৌশল কাজের সংস্থা IETF-এর বিশ্লেষণ—RFC 9518-এ উল্লেখ করা হয়েছে যে দুটি পক্ষের মধ্যে সংযোগ ঘটানোর জন্য প্রায়শই তৃতীয় একটি পক্ষের প্রয়োজন হয়, যা মূলত কেন্দ্রীয় পয়েন্টগুলো তৈরি হওয়ার অন্যতম প্রধান কারণ। নিচের ৪টি ডিজাইন এই প্রশ্নগুলোর উত্তর ভিন্ন ভিন্নভাবে দিয়ে থাকে।

৪টি ডিজাইন

১. সেন্ট্রালাইজড (Centralized)

এখানে একটিমাত্র সংস্থা বা প্রতিষ্ঠান সার্ভার, সফটওয়্যার এবং নিয়মাবলী পরিচালনা করে। সিগন্যাল (Signal) এর সবচেয়ে বহুল পরিচিত উদাহরণ। ২০১৬ সালে এর প্রতিষ্ঠাতা এই ডিজাইনের কারণ ব্যাখ্যা করে বলেছিলেন: তিনি যুক্তি দেন যে ফেডারেটেড প্রোটোকলগুলো পরিবর্তন করা কঠিন, তিনি আর বিশ্বাস করেন না যে প্রতিযোগিতা করার মতো কোনো ফেডারেটেড মেসেঞ্জার তৈরি করা সম্ভব, এবং মেটাডেটা সুরক্ষা দিতে নতুন প্রোটোকলের প্রয়োজন যা “একক নিয়ন্ত্রণ থাকা সেন্ট্রালাইজড পরিবেশেই কেবল দ্রুত বাস্তবায়ন সম্ভব।” তিনি আরও যোগ করেন যে ওপেন সোর্স অবকাঠামো থাকার কারণে প্রোভাইডার কোনো খারাপ পরিবর্তন আনলে ব্যবহারকারীরা তাদের নিজস্ব বিকল্প তৈরি করে চালাতে পারেন (Signal, 2016)। সিদ্ধান্ত গ্রহণকারী ব্যক্তির কাছ থেকে এটি একটি বাস্তব মতভেদের একপাশের যুক্তি।

এর ভালো দিক হলো প্রোভাইডার যেকোনো সমস্যা দ্রুত সমাধান করতে পারে এবং পুরো সিস্টেমের ডিজাইন ঠিক রাখতে পারে। আর অসুবিধা হলো ওই একটি সংস্থা এবং তাদেরকে বাধ্য করতে পারা যেকোনো ব্যক্তি বা কর্তৃপক্ষ সমস্ত ডাটা ট্রাফিক দেখতে পায়। প্রোভাইডার কী দেখতে পাবে তা নির্ভর করে তারা কী সংগ্রহ করছে তার ওপর। ২০২১ সালে মার্কিন যুক্তরাষ্ট্রের একটি আদালতের পরোয়ানা বা সার্চ ওয়ারেন্টের জবাবে সিগন্যাল জানিয়েছিল যে তারা কেবল প্রতিটি অ্যাকাউন্ট তৈরির সময় এবং সর্বশেষ কানেক্ট হওয়ার তারিখ প্রদান করতে সক্ষম (Signal, 2021)। এর “Sealed sender” ফিচারটি সার্ভিসের কাছ থেকে প্রেরকের পরিচয় লুকিয়ে রাখে, তবে তাদের অফিশিয়াল পোস্টে বলা হয়েছে সার্ভিসকে এখনো প্রাপকের তথ্য জানতে হয় এবং সময় ও আইপি ঠিকানার বিষয়টি নিয়ে এখনো কাজ চলছে (Signal, 2018)। সিগন্যালে রেজিস্ট্রেশনের জন্য এখনো ফোন নম্বরের প্রয়োজন হয়। ইউজারনেম ব্যবহার করা ঐচ্ছিক, যা আপনার নম্বর না জানিয়েও অন্যদের যোগাযোগের সুযোগ দেয় (Signal Support)।

২. ফেডারেটেড (Federated)

বিভিন্ন মানুষের পরিচালিত অনেকগুলো স্বাধীন সার্ভার একটি সাধারণ স্ট্যান্ডার্ডের অধীনে একে অপরের সাথে কথা বলে। আপনি আপনার অ্যাকাউন্ট রাখার জন্য যেকোনো একটি সার্ভার বেছে নেন এবং সেটি অন্যান্য সার্ভারের সাথে বার্তা বিনিময় করে। ইমেইল হলো এর সবচেয়ে পুরোনো উদাহরণ: SMTP প্রোটোকল একটি সার্ভারকে বার্তা গ্রহণ করতে এবং তারপর পথের পরবর্তী সার্ভারের জন্য ক্লায়েন্ট হিসেবে কাজ করার সুযোগ দেয় (RFC 5321, 2008)। চ্যাটিংয়ের জন্য মেট্রিক্স (Matrix) একইভাবে কাজ করে। প্রতিটি ব্যবহারকারীর অ্যাকাউন্ট তাদের নিজস্ব ‘হোমসার্ভারে’ থাকে এবং প্রতিটি চ্যাট রুম সেই সব হোমসার্ভারে প্রতিলিপি বা কপি হয় যেগুলোর সদস্যরা সেখানে যুক্ত রয়েছে (Matrix)। ২০১৮ সালের জানুয়ারি থেকে W3C স্ট্যান্ডার্ড হিসেবে স্থান পাওয়া ActivityPub সোশ্যাল নেটওয়ার্কের জন্য এই কাজ করে, যেখানে সার্ভারগুলো একে অপরের ইনবক্সে বিভিন্ন আপডেট পোস্ট করে (W3C)।

এর সুবিধা হলো পছন্দের স্বাধীনতা: আপনি নিজের সার্ভার বেছে নিতে বা নিজেই একটি চালাতে পারেন, এবং কোনো একক কোম্পানি পুরো নেটওয়ার্কের মালিক নয়। আর অসুবিধা হলো আপনার সার্ভার অপারেটর আপনার অ্যাকাউন্টের কার্যক্রম দেখতে পায়, এবং আপনার পরিচিতরা যেসব সার্ভার ব্যবহার করে সেগুলোর অপারেটররাও তা দেখতে পায়। ম্যাট্রিক্স এটি প্রকাশ্যে স্বীকার করে। তারা জানায় যে কারা কোন রুমে কথা বলছে—সেই মেটাডেটা তারা সংশ্লিষ্ট সার্ভারের অ্যাডমিনদের কাছে প্রকাশ করে (Matrix, 2025)। অন্যদিকে ActivityPub স্ট্যান্ডার্ড তৈরির সময় সর্বসম্মত কোনো অথেনটিকেশন বা যাচাইকরণ ব্যবস্থা রাখা হয়নি এবং এতে সরাসরি মেসেজ বা ডিএম এনক্রিপ্ট করার বিষয়ে কিছুই বলা হয়নি।

ইমেইল এর দ্বিতীয় সীমাবদ্ধতা দেখায়। আপনার মেইল অ্যাপ এবং সার্ভারের মধ্যকার কানেকশন সুরক্ষার স্ট্যান্ডার্ড, RFC 8314 বলছে যে সার্ভারগুলো কীভাবে একে অপরের কাছে মেইল পাঠায় তা নিয়ে এটি কোনো কাজ করে না। আর IETF-এর একটি খসড়ায় উল্লেখ করা হয়েছে যে PGP/MIME এনক্রিপশন একাই বার্তার হেডার বা পরিচয়সংক্রান্ত অংশ সুরক্ষিত করতে পারে না (IETF draft, 2019)।

৩. পিয়ার-টু-পিয়ার (Peer-to-peer)

এখানে মাঝে কোনো সার্ভার থাকে না। ডিভাইসগুলো সরাসরি একে অপরের সাথে বার্তা বিনিময় করে। ব্রায়ার (Briar)-এর প্রজেক্ট সাইট বিষয়টিকে এভাবে বর্ণনা করে: এটি কোনো কেন্দ্রীয় সার্ভারের ওপর নির্ভর করে না, বার্তাগুলো সরাসরি ব্যবহারকারীদের ডিভাইসে সিঙ্ক হয় এবং কন্টাক্ট লিস্টগুলো এনক্রিপ্ট করে প্রতিটি ডিভাইসে সংরক্ষিত থাকে। ইন্টারনেট সচল থাকলে এটি টর (Tor)-এর ওপর দিয়ে সিঙ্ক হয়, যা প্রজেক্টের ভাষ্যমতে কোন ব্যবহারকারীরা কার সাথে যোগাযোগ করছে তা নজরদারকারীদের দেখা থেকে বিরত রাখে। আর ইন্টারনেট বন্ধ থাকলে ব্লুটুথ, ওয়াই-ফাই বা মেমোরি কার্ডের মাধ্যমে ডাটা আদান-প্রদান হতে পারে। যেসব মানুষ একই সাথে অনলাইনে থাকে না, তাদের জন্য একটি পৃথক ‘Briar Mailbox’ বার্তা পৌঁছে দেওয়ার কাজ করে (Briar)।

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

৪. অ্যাকাউন্ট ছাড়া রিলে নেটওয়ার্ক (Relay networks without user accounts)

একটি নতুন ডিজাইন যা ব্যবহারকারীর আইডেন্টিফায়ার বা পরিচয় পুরোপুরি এড়িয়ে চলে। সিম্প্লেক্স (SimpleX) নিজেদের এভাবে বর্ণনা করে: ব্যবহারকারীদের কোনো ফোন নম্বর, ইউজারনেম বা পাবলিক কী দেওয়া হয় না। বার্তাগুলো একমুখী কিউ ঠিকানার (Queue address) মাধ্যমে রিলে সার্ভারের মধ্য দিয়ে যায়—যেখানে প্রতিটি কন্টাক্টের জন্য আলাদা আলাদা ঠিকানা থাকে এবং সার্ভারগুলো কেবল সাময়িকভাবে বার্তাগুলো জমা রাখে। প্রজেক্টটি জানায় যে সার্ভারগুলোর পক্ষে সহজেই বোঝা সম্ভব নয় কে কার সাথে কথা বলছে, তবে ট্রাফিক অ্যানালাইসিস আক্রমণের সম্ভাবনা থেকে যায় (SimpleX)। অন্যান্য ডিজাইনের সাথে এর তুলনাগুলো প্রকল্পটির নিজস্ব, যা আমরা স্বাধীনভাবে পরীক্ষা করিনি। তাছাড়া ইনভিটেশন লিংক বা সাময়িক ঠিকানা শেয়ার না করে এতে কারো সাথে যোগাযোগ করা সম্ভব নয়।

টর (Tor) এর সাথে সম্পর্কিত হলেও একটু ভিন্ন ধরনের নেটওয়ার্ক। এটি কয়েকটি রিলের মধ্য দিয়ে ট্রাফিক চালনা করে যাতে একক কোনো রিলে আপনার পরিচয় এবং গন্তব্য—উভয়ই জানতে না পারে। আমাদের টর পরিচিতি (Tor overview) পেজে এটি ব্যাখ্যা করা হয়েছে।

প্রতিটি ডিজাইন কার কাছে কী প্রকাশ করে

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

এই ডিজাইনগুলো যা করতে পারে না

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

সাধারণ কিছু ভুল ধারণা

“ডিসেন্ট্রালাইজড মানেই প্রাইভেট।” এর মানে হলো নিয়ন্ত্রণ ছড়িয়ে দেওয়া হয়েছে। ফেডারেটেড নেটওয়ার্কের প্রতিটি অপারেটর তার নিজস্ব ব্যবহারকারীদের মেটাডেটা দেখতে পায়, যা ম্যাট্রিক্স নিজের সম্পর্কে স্পষ্ট বলে।

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

“এন্ড-টু-এন্ড এনক্রিপশন আমি কার সাথে কথা বলছি তা লুকিয়ে রাখে।” এটি কেবল ভেতরের বার্তা সুরক্ষিত রাখে। বার্তা পৌঁছে দেওয়ার জন্য একটি ঠিকানার প্রয়োজন হয়, এবং সিগন্যালের নিজস্ব পোস্টে বলা হয়েছে যে তাদের সার্ভিসকে প্রাপকের তথ্য জানতে হয়।

আপনার করণীয়

এগুলো সর্বনিম্ন পরিশ্রমে সর্বোচ্চ সুবিধার ক্রমানুসারে সাজানো হয়েছে:

১. প্রথমে কার কাছ থেকে আত্মগোপন করছেন তা ঠিক করুন: একজন সাধারণ উৎসুক ব্যক্তি, নেটওয়ার্ক অপারেটর, কোম্পানি নাকি কোনো সরকার—সবার জন্য আলাদা ডিজাইনের প্রয়োজন। আমাদের থ্রেট মডেলিং (Threat modeling) দিয়ে শুরু করুন।
২. অপারেটর কী দেখতে পায় তা বিবেচনা করে বেছে নিন, কেবল “ডিসেন্ট্রালাইজড” শব্দের ওপর ভিত্তি করে নয়: অপারেটর কী ধরনের অ্যাকাউন্ট বিবরণী এবং মেটাডেটা জমা রাখছে এবং আইনি দাবির জবাবে তারা অতীতে কী দিয়েছে তা খতিয়ে দেখুন।
৩. ফেডারেটেড সার্ভিস ব্যবহার করলে ভেবেচিন্তে সার্ভার বেছে নিন: আপনার সার্ভার অপারেটর আপনার কার্যক্রম দেখতে পারে। সার্ভারটি কে এবং কোথা থেকে চালাচ্ছে তা পড়ে নিন। নিজের সার্ভার নিজে চালালে বিশ্বাসটি নিজের ওপর আসে, তবে রক্ষণাবেক্ষণের দায়িত্ব বাড়ে।
৪. ফোন নম্বর সংবেদনশীল হলে নম্বর ছাড়া ব্যবহারের সুবিধা দেয় এমন মাধ্যম বেছে নিন: সিগন্যালের ইউজারনেম সুবিধা এবং সিম্প্লেক্সের মতো অ্যাকাউন্ট ছাড়া তৈরি ডিজাইনগুলো ভিন্ন ভিন্ন সুবিধার বিনিময়ে এই সমস্যার সমাধান দেয়।
৫. আপনার নিয়মিত নেটওয়ার্ক ব্লক হওয়ার দিনের জন্য প্রস্তুত থাকুন: পিয়ার-টু-পিয়ার টুল (যেমন ব্রায়ার) এবং ব্রিজ সুবিধাযুক্ত টুল (যেমন টর) এই কাজের জন্য রয়েছে, তবে প্রয়োজন হওয়ার আগেই সেগুলো ইনস্টল ও পরীক্ষা করে নিন।
৬. আপনার পরিচিতরা বাস্তবে যে নেটওয়ার্ক ব্যবহার করবে সেটি ব্যবহার করুন: একটি অতি-সুরক্ষিত প্রাইভেট টুল যা কেউ ব্যবহার করে না এবং উত্তর দেয় না, তা কাউকে সুরক্ষা দিতে পারে না। যোগাযোগের নেটওয়ার্ক পরিবর্তনের ঝামেলার বিষয়টিও নিরাপত্তারই অংশ।

উৎসসমূহ (Sources)

সম্পর্কিত পেজসমূহ

সাধারণ জিজ্ঞাসা