RadSec: কীভাবে TLS এর মাধ্যমে RADIUS, WiFi অথেনটিকেশন সিকিউরিটি উন্নত করে

RadSec: কীভাবে RADIUS over TLS WiFi অথেন্টিকেশন সিকিউরিটি উন্নত করে একটি Purple Enterprise WiFi ইন্টেলিজেন্স ব্রিফিং আনুমানিক সময়কাল: ১০ মিনিট --- [ভূমিকা ও প্রসঙ্গ - আনুমানিক ১ মিনিট] Purple Enterprise WiFi ইন্টেলিজেন্স সিরিজে আপনাকে স্বাগত জানাই। আমি আপনার হোস্ট, এবং আজ আমরা এমন একটি বিষয় নিয়ে আলোচনা করছি যা ঠিক নেটওয়ার্ক সিকিউরিটি এবং অপারেশনাল রিস্ক-এর সংযোগস্থলে অবস্থান করে: RadSec - যা আনুষ্ঠানিকভাবে RFC 6614-এ সংজ্ঞায়িত করা হয়েছে - এবং আপনার ইনফ্রাস্ট্রাকচার রোডম্যাপে এটি কেন ইতিমধ্যে না থাকলে এখনই যুক্ত করা উচিত। আপনি যদি একজন আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট, বা CTO হন যিনি কোনো হোটেল গ্রুপ, রিটেইল এস্টেট, স্টেডিয়াম, বা পাবলিক-সেক্টর ক্যাম্পাস জুড়ে এন্টারপ্রাইজ WiFi-এর দায়িত্বে আছেন, তবে এই ব্রিফিংটি আপনার জন্য। আমরা আলোচনা করব আসলে RadSec কী, কেন ট্র্যাডিশনাল RADIUS প্রোটোকল আপনাকে অরক্ষিত অবস্থায় ফেলে রাখে, কীভাবে একটি বাস্তব-জগতের পরিবেশে RadSec ডিপ্লয় করবেন, এবং কোন কোন ভুলের কারণে টিমগুলো সমস্যায় পড়ে। তাত্ত্বিক আলোচনার জন্য শুধু তত্ত্ব নয় - এই কোয়ার্টারে আপনার সিদ্ধান্ত নেওয়ার জন্য প্রয়োজনীয় সঠিক তথ্যই আমরা এখানে দেব। চলুন শুরু করা যাক। --- [টেকনিক্যাল ডিপ-ডাইভ - আনুমানিক ৫ মিনিট] তাহলে, সমস্যাটি দিয়ে শুরু করা যাক। RADIUS - রিমোট অথেন্টিকেশন ডায়াল-ইন ইউজার সার্ভিস - ১৯৯০-এর দশক থেকেই এন্টারপ্রাইজ WiFi অথেন্টিকেশনের মেরুদণ্ড হিসেবে কাজ করছে। যখন কোনো ইউজার বা ডিভাইস আপনার কর্পোরেট বা গেস্ট WiFi-এর সাথে কানেক্ট হয়, তখন অ্যাক্সেস পয়েন্টটি একটি RADIUS ক্লায়েন্ট হিসেবে কাজ করে, যা অথেন্টিকেশন রিকোয়েস্টগুলোকে একটি RADIUS সার্ভারে ফরোয়ার্ড করে। এই সার্ভারটি অ্যাক্টিভ ডিরেক্টরি, LDAP, বা কোনো ক্লাউড আইডেন্টিটি প্রোভাইডারের সাথে ক্রেডেনশিয়াল যাচাই করে এবং অ্যাক্সেস অনুমোদন বা প্রত্যাখ্যান করে। এটিই হলো 802.1X অথেন্টিকেশন মডেল যা WPA2 এবং WPA3 নেটওয়ার্কগুলোকে সচল রাখে। সমস্যা হলো, ট্র্যাডিশনাল RADIUS ডিজাইন করা হয়েছিল অন্য একটি যুগের জন্য। এটি UDP - ইউজার ডেটাগ্রাম প্রোটোকল - এর মাধ্যমে ১৮১২ এবং ১৮১৩ পোর্টে রান করে। UDP হলো কানেকশনলেস, যার অর্থ এতে কোনো হ্যান্ডশেক নেই, কোনো সেশন স্টেট নেই এবং সবচেয়ে বড় কথা, কোনো নেটিভ এনক্রিপশন নেই। আপনার অ্যাক্সেস পয়েন্ট এবং RADIUS সার্ভারের মধ্যে একমাত্র সুরক্ষা হলো একটি শেয়ার্ড সিক্রেট - মূলত একটি পাসওয়ার্ড - যা MD5 হ্যাশিং ব্যবহার করে ট্রানজিটের সময় ইউজারের পাসওয়ার্ড গোপন রাখতে ব্যবহৃত হয়। MD5, আপনারা অনেকেই হয়তো জানেন, ক্রিপ্টোগ্রাফিকভাবে ভেঙে গেছে। এটি বছরের পর বছর ধরে অকার্যকর অবস্থায় আছে। বাস্তবে এর অর্থ কী? এর অর্থ হলো, নেটওয়ার্কের যে কোনো অংশে যেখানে একজন আক্রমণকারী RADIUS ট্রাফিক ইন্টারসেপ্ট করতে পারে - যার মধ্যে রয়েছে কম্প্রোমাইজড সুইচ, আপনার ম্যানেজমেন্ট VLAN-এ থাকা ক্ষতিকর ডিভাইস, বা একটি রিমোট অ্যাক্সেস পয়েন্ট এবং ক্লাউড-হোস্টেড RADIUS সার্ভারের মধ্যবর্তী যে কোনো পয়েন্ট - সেখানে তারা সম্ভাব্যভাবে অথেন্টিকেশন এক্সচেঞ্জগুলো ক্যাপচার করতে পারে, শেয়ার্ড সিক্রেটের বিরুদ্ধে অফলাইন ডিকশনারি অ্যাটাক চালাতে পারে এবং কিছু কনফিগারেশনে ইউজারের ক্রেডেনশিয়াল সম্পূর্ণ উন্মুক্ত করে দিতে পারে। ২০০টি প্রপার্টি জুড়ে গেস্ট WiFi চালানো একটি হোটেল গ্রুপ, অথবা প্রতিটি স্টোরে থাকা অ্যাক্সেস পয়েন্ট থেকে পাবলিক ইন্টারনেটের মাধ্যমে একটি সেন্ট্রাল RADIUS সার্ভারে ডেটা পাঠানো একটি রিটেইল চেইনের জন্য, এটি কোনো তাত্ত্বিক ঝুঁকি নয়। এটি একটি সক্রিয় অ্যাটাক সারফেস।এটি ঠিক সেই সমস্যা যা RadSec সমাধান করে। RadSec - যা RFC 6614-এ সংজ্ঞায়িত এবং RFC 7360 দ্বারা আপডেট করা হয়েছে - একটি TLS টানেলের মধ্যে RADIUS ট্রাফিককে আবৃত করে। UDP-এর পরিবর্তে, এটি পোর্ট ২০৮৩-এ TCP ব্যবহার করে। একটি শেয়ার্ড সিক্রেট এবং MD5-এর পরিবর্তে, এটি X.509 সার্টিফিকেট সহ মিউচুয়াল TLS প্রমাণীকরণ ব্যবহার করে। কোনো প্রমাণীকরণ ডেটা আদান-প্রদান করার আগে RADIUS ক্লায়েন্ট এবং RADIUS সার্ভার উভয়ই সার্টিফিকেট প্রদর্শন করে, একে অপরের পরিচয় যাচাই করে এবং একটি এনক্রিপ্ট করা সেশন স্থাপন করে। TLS 1.3 হল বর্তমান প্রস্তাবিত সংস্করণ, যা ফরোয়ার্ড সিক্রেসি প্রদান করে এবং একাধিক লিগ্যাসি সাইফার দুর্বলতা দূর করে। এর ব্যবহারিক প্রভাব অত্যন্ত তাৎপর্যপূর্ণ। ক্রেডেনশিয়াল ডেটা, ব্যবহারকারীর বৈশিষ্ট্য এবং সেশন টোকেনগুলো অ্যাক্সেস পয়েন্ট - অথবা একটি RadSec প্রক্সি - এবং RADIUS সার্ভারের মধ্যে এন্ড-টু-এন্ড এনক্রিপ্ট করা হয়। ওয়্যারে ট্রাফিককে বাধা প্রদানকারী কোনো আক্রমণকারী কেবল এনক্রিপ্ট করা TLS রেকর্ড দেখতে পাবে। ব্যাকওয়ার্ড সামঞ্জস্যের জন্য শেয়ার্ড সিক্রেটটি এখনও উপস্থিত থাকে, কিন্তু এটি আর কোনো অর্থপূর্ণ সুরক্ষার কাজ করে না - মূলত TLS-ই পুরো লোড বহন করে। এখানে আরও একটি মাত্রা রয়েছে যা দিন দিন প্রাসঙ্গিক হয়ে উঠছে: রোমিং। ইউরোপ এবং তার বাইরেও বিশ্ববিদ্যালয় এবং গবেষণা প্রতিষ্ঠানগুলো দ্বারা ব্যবহৃত Eduroam ফেডারেশন তাদের আন্তঃ-প্রাতিষ্ঠানিক রোমিং পরিকাঠামোর অংশ হিসাবে বছরের পর বছর ধরে RadSec চালাচ্ছে। আরও সম্প্রতি, Wi-Fi Alliance-এর OpenRoaming স্ট্যান্ডার্ড - যা অংশগ্রহণকারী স্থানগুলোতে নিরবচ্ছিন্ন WiFi রোমিং সক্ষম করে - সমস্ত ফেডারেশন ট্রাফিকের জন্য RadSec বাধ্যতামূলক করেছে। আপনি যদি OpenRoaming-সক্ষম পরিকাঠামো স্থাপন করেন, তবে RadSec ঐচ্ছিক নয়; এটি একটি পূর্বশর্ত। Purple তার Connect লাইসেন্সের অধীনে OpenRoaming সমর্থন করে, ফেডারেশনের মধ্যে একটি আইডেন্টিটি প্রোভাইডার হিসাবে কাজ করে এবং RadSec হল সেই সুরক্ষিত রোমিং কাঠামো কীভাবে কাজ করে তার মূল ভিত্তি। সম্মতির দৃষ্টিকোণ থেকে, RadSec ক্রমশ PCI DSS 4.0-এর সাথে আরও প্রাসঙ্গিক হয়ে উঠছে, যা ট্রানজিটে প্রমাণীকরণ ডেটা সুরক্ষার নিয়মগুলোকে আরও কঠোর করে। যদি আপনার WiFi পরিকাঠামো পেমেন্ট কার্ড এনভায়রনমেন্টের সংস্পর্শে আসে - এবং রিটেল ও হসপিটালিটি সেক্টরে এটি প্রায়শই ঘটে - তবে প্রথাগত RADIUS-এর এই এনক্রিপশন ফাঁকটি একটি বড় দুর্বলতা হিসাবে চিহ্নিত হতে পারে। একইভাবে, GDPR ব্যক্তিগত ডেটা সুরক্ষার জন্য উপযুক্ত প্রযুক্তিগত ব্যবস্থার দাবি করে; আপনার নেটওয়ার্ক জুড়ে এনক্রিপ্ট ছাড়া প্রবাহিত ব্যবহারকারীর ক্রেডেনশিয়াল এবং সেশন মেটাডেটা একটি ডেটা সুরক্ষা অডিটে রক্ষা করা কঠিন। এখন আর্কিটেকচার নিয়ে আলোচনা করা যাক। RadSec-এর জন্য মূলত দুটি প্রাথমিক ডেপ্লয়মেন্ট প্যাটার্ন রয়েছে। প্রথমটি হলো আপনার RADIUS সার্ভার এবং অ্যাক্সেস পয়েন্টগুলোতে নেটিভ RadSec সমর্থন। FreeRADIUS 3.0 এবং তার পরবর্তী সংস্করণগুলো নেটিভলি RadSec সমর্থন করে। Microsoft NPS বর্তমান রিলিজ পর্যন্ত নেটিভলি RadSec সমর্থন করে না, যা Windows-কেন্দ্রিক পরিকাঠামো চালানো সংস্থাগুলোর জন্য একটি বড় সীমাবদ্ধতা। Cisco ISE RadSec সমর্থন করে। Aruba ClearPass RadSec সমর্থন করে। যদি আপনার RADIUS সার্ভার এবং আপনার অ্যাক্সেস পয়েন্ট ভেন্ডর উভয়ই নেটিভলি RadSec সমর্থন করে, তবে এটি সবচেয়ে সহজ পথ - উভয় প্রান্তে TLS সার্টিফিকেট কনফিগার করুন, আপনার ফায়ারওয়ালে TCP 2083 পোর্টটি খুলুন এবং আপনি এন্ড-টু-এন্ড RADIUS ট্রাফিক এনক্রিপ্ট করছেন। দ্বিতীয় প্যাটার্নটি হলো একটি RadSec প্রক্সি। এটি বাস্তবে আরও সাধারণ ডেপ্লয়মেন্ট, বিশেষ করে লিগ্যাসি RADIUS ইনফ্রাস্ট্রাকচার বা মিশ্র-ভেন্ডর এনভায়রনমেন্ট সহ প্রতিষ্ঠানগুলোর জন্য। একটি RadSec প্রক্সি - radsecproxy হলো সবচেয়ে ব্যাপকভাবে ব্যবহৃত ওপেন সোর্স ইমপ্লিমেন্টেশন - আপনার অ্যাক্সেস পয়েন্ট এবং আপনার RADIUS সার্ভারের মধ্যে অবস্থান করে। অ্যাক্সেস পয়েন্টগুলো লোকাল নেটওয়ার্কে প্রক্সির কাছে UDP-এর মাধ্যমে স্ট্যান্ডার্ড RADIUS পাঠায়। প্রক্সি সেই কানেকশনটি বন্ধ করে, RADIUS ট্রাফিককে একটি TLS টানেলের ভেতরে পুনরায় এনক্যাপসুলেট করে এবং TCP 2083-এর মাধ্যমে আপস্ট্রিম RADIUS সার্ভারে ফরোয়ার্ড করে। এই অ্যাপ্রোচটি আপনাকে আপনার RADIUS সার্ভার প্রতিস্থাপন না করেই একটি বিদ্যমান ইনফ্রাস্ট্রাকচারে RadSec যুক্ত করতে দেয়, এবং এটি বিশেষ করে তখন উপযোগী যখন আপনার RADIUS সার্ভার ক্লাউডে হোস্ট করা থাকে বা পাবলিক ইন্টারনেটের মাধ্যমে অ্যাক্সেস করা হয়। সার্টিফিকেট ম্যানেজমেন্ট হলো অপারেশনাল জটিলতা যার জন্য আপনাকে পরিকল্পনা করতে হবে। মিউচুয়াল TLS-এর জন্য ব্যবহৃত X.509 সার্টিফিকেটগুলো ইস্যু ও পরিচালনা করতে আপনার একটি PKI - Public Key Infrastructure - প্রয়োজন হবে। এর অর্থ হলো একটি সার্টিফিকেট অথরিটি, প্রতিটি RADIUS ক্লায়েন্ট এবং সার্ভারের জন্য সার্টিফিকেট ইস্যু করা এবং মেয়াদ শেষ হওয়ার আগে সার্টিফিকেট রোটেশনের একটি প্রক্রিয়া। যে সার্টিফিকেটের মেয়াদ অলক্ষ্যে শেষ হয়ে যায় তা আপনার নেটওয়ার্কের প্রতিটি ব্যবহারকারীর জন্য একই সাথে অথেন্টিকেশন ব্যাহত করবে - এবং এটি এমন একটি পরিস্থিতি যা আপনি এড়াতে চান। ACME বা আপনার CA-এর API ব্যবহার করে সার্টিফিকেট রিনিউয়াল স্বয়ংক্রিয় করুন এবং মেয়াদ শেষ হওয়ার তারিখের অনেক আগেই মনিটরিং অ্যালার্ট সেট করুন। - [ইমপ্লিমেন্টেশন সুপারিশ ও সমস্যাসমূহ - প্রায় ২ মিনিট] আপনাকে কিছু ব্যবহারিক সুপারিশ দেওয়া যাক। প্রথমত: ডেপ্লয় করার আগে অডিট করুন। আপনার এনভায়রনমেন্টের প্রতিটি RADIUS ক্লায়েন্ট - অ্যাক্সেস পয়েন্ট, VPN কনসেনট্রেটর, 802.1X করা সুইচ - এবং প্রতিটি RADIUS সার্ভার ম্যাপ করুন। কোনগুলো নেটিভভাবে RadSec সাপোর্ট করে এবং কোনগুলোর জন্য প্রক্সি লাগবে তা বুঝে নিন। এই অডিটটি সাধারণত এমন লিগ্যাসি ডিভাইসগুলোকে সামনে নিয়ে আসে যেগুলো মোটেও TLS সাপোর্ট করে না, এবং সেগুলোকে আপনার প্রতিস্থাপনের রোডম্যাপে রাখা প্রয়োজন। দ্বিতীয়ত: সবচেয়ে ঝুঁকিপূর্ণ ট্রাফিক দিয়ে শুরু করুন। আপনার যদি পাবলিক ইন্টারনেটের মাধ্যমে RADIUS ট্রাফিক যাতায়াত করে - যেমন রিমোট সাইট, ক্লাউড-হোস্টেড RADIUS, মাল্টি-প্রপার্টি হোটেল গ্রুপ - তবে সেটি আপনার প্রথম অগ্রাধিকার। একটি সু-বিভক্ত ম্যানেজমেন্ট VLAN-এ লোকাল RADIUS ট্রাফিকের ঝুঁকি কম, তবে এটিও রোডম্যাপে থাকা উচিত। তৃতীয়ত: গো-লাইভ করার আগে মিউচুয়াল TLS পুঙ্খানুপুঙ্খভাবে পরীক্ষা করুন। RadSec ডেপ্লয়মেন্টে সবচেয়ে সাধারণ ব্যর্থতার মোড হলো সার্টিফিকেট ভ্যালিডেশন ত্রুটি - যেমন অমিল থাকা Common Names, মেয়াদোত্তীর্ণ ইন্টারমিডিয়েট সার্টিফিকেট, অথবা ক্লায়েন্টরা সার্ভার সার্টিফিকেটে স্বাক্ষরকারী CA-কে বিশ্বাস না করা। প্রোডাকশন ট্রাফিক চালু করার আগে TLS হ্যান্ডশেক পরীক্ষা করতে openssl s_client ব্যবহার করুন। চতুর্থত: মনিটরিং অবহেলা করবেন না। RadSec একটি TCP কানেকশন লেয়ার যুক্ত করে যা ঐতিহ্যবাহী RADIUS-এ থাকে না। TCP কানেকশন ব্যর্থতা, TLS হ্যান্ডশেক টাইমআউট এবং সার্টিফিকেট ত্রুটিগুলো আপনার ব্যবহারকারীদের জন্য অথেন্টিকেশন ব্যর্থতা হিসেবে প্রকাশ পাবে। নিশ্চিত করুন যে আপনার RADIUS সার্ভার লগ এবং আপনার প্রক্সি লগগুলো আপনার SIEM বা মনিটরিং প্ল্যাটফর্মে যুক্ত হচ্ছে যাতে আপনি একটি RadSec কানেক্টিভিটি সমস্যা থেকে একটি অথেন্টিকেশন পলিসি সমস্যা আলাদা করতে পারেন। সবচেয়ে বেশি যে ভুলটি আমি হতে দেখি তা হলো সংস্থাগুলি সার্ভার সাইডে RadSec স্থাপন করে কিন্তু তাদের ফায়ারওয়াল নিয়মগুলি আপডেট করতে ভুলে যায়। প্রতিটি RADIUS ক্লায়েন্ট এবং RADIUS সার্ভার বা প্রক্সির মধ্যে TCP 2083 খোলা থাকা প্রয়োজন। আপনি যদি UDP 1812 নিয়মগুলি পরিচালনা করতে অভ্যস্ত হন, তবে ফায়ারওয়াল পরিবর্তন প্রক্রিয়ার সময় TCP 2083 বাদ পড়ে যেতে পারে। - - - [র‌্যাপিড-ফায়ার প্রশ্নোত্তর - প্রায় ১ মিনিট] আমি নিয়মিত যে কয়েকটি প্রশ্ন শুনি সেগুলি সংক্ষেপে দেখে নেওয়া যাক। "RadSec কি 802.1X কে প্রতিস্থাপন করে?" না। RadSec অ্যাক্সেস পয়েন্ট এবং RADIUS সার্ভারের মধ্যে ট্রান্সপোর্ট লেয়ারকে সুরক্ষিত করে। 802.1X হলো ক্লায়েন্ট ডিভাইস এবং অ্যাক্সেস পয়েন্টের মধ্যে অথেন্টিকেশন ফ্রেমওয়ার্ক। এগুলি বিভিন্ন লেয়ারে কাজ করে এবং একে অপরের পরিপূরক। "RadSec কি সব অ্যাক্সেস পয়েন্ট ভেন্ডরে সমর্থিত?" সার্বজনীনভাবে নয়। Cisco, Aruba, Ruckus এবং Meraki সবারই RadSec সমর্থনের বিভিন্ন স্তর রয়েছে - আপনার নির্দিষ্ট ফার্মওয়্যার সংস্করণটি পরীক্ষা করে দেখুন। যেখানে নেটিভ সাপোর্ট নেই, সেখানে একটি RadSec প্রক্সিই আপনার সমাধান। "DTLS - RADIUS over DTLS সম্পর্কে কী বলা যায়?" RFC 7360 RADIUS over DTLS কে সংজ্ঞায়িত করে, যা TCP-এর পরিবর্তে UDP ব্যবহার করে, এনক্রিপশন যুক্ত করার সাথে সাথে ট্র্যাডিশনাল RADIUS-এর সংযোগহীন কিছু বৈশিষ্ট্য বজায় রাখে। এটি TLS-এর মাধ্যমে RadSec-এর মতো অতটা ব্যাপকভাবে ব্যবহৃত হয় না তবে উচ্চ-থ্রুপুটযুক্ত পরিবেশে লেটেন্সি একটি উদ্বেগের বিষয় হলে এটি মূল্যায়ন করা উচিত। "এটি রোমিং পারফরম্যান্সকে কীভাবে প্রভাবিত করে?" RadSec-এর TCP কানেকশনটি পারসিস্টেন্ট বা স্থায়ী, যা পরবর্তী অথেন্টিকেশন অনুরোধগুলির জন্য কানেকশন সেটআপের ওভারহেড কমিয়ে ফেডারেটেড পরিবেশে রোমিং পারফরম্যান্সকে আসলে আরও উন্নত করতে পারে। - - - [সংক্ষিপ্তসার ও পরবর্তী পদক্ষেপ - প্রায় ১ মিনিট] উপসংহারে বলা যায়: RadSec হলো ট্র্যাডিশনাল RADIUS-এর একটি প্রকৃত নিরাপত্তা ঘাটতির পরিপক্ক, স্ট্যান্ডার্ড-ভিত্তিক সমাধান। আপনি যদি বড় পরিসরে এন্টারপ্রাইজ WiFi পরিচালনা করেন - একাধিক সাইট জুড়ে, ইন্টারনেটের মাধ্যমে, অথবা PCI-DSS বা GDPR-এর আওতাধীন পরিবেশে - তবে প্রশ্নটি RadSec মোতায়েন করবেন কিনা তা নয়, বরং এটি কখন এবং কীভাবে করবেন তা নিয়ে। আপনার পরবর্তী পদক্ষেপ: এই সপ্তাহে আপনার RADIUS অবকাঠামো অডিট করুন। আপনার সবচেয়ে ঝুঁকিপূর্ণ ট্রাফিক ফ্লো চিহ্নিত করুন। নেটিভ RadSec সমর্থনের জন্য আপনার RADIUS সার্ভার এবং অ্যাক্সেস পয়েন্ট ভেন্ডর ডকুমেন্টেশন পরীক্ষা করুন। আপনি যদি FreeRADIUS ব্যবহার করেন, তবে আপনি একদিনের মধ্যেই একটি পরীক্ষামূলক RadSec মোতায়েন শুরু করতে পারেন। আপনি যদি Microsoft NPS ব্যবহার করেন, তবে একটি প্রক্সি বা RadSec-সক্ষম সার্ভারে স্থানান্তরিত হওয়ার পথ মূল্যায়ন করা শুরু করুন। Purple-এর প্ল্যাটফর্মটি এন্টারপ্রাইজ RADIUS অবকাঠামোর সাথে একীভূত করার জন্য ডিজাইন করা হয়েছে, যা কর্পোরেট এবং গেস্ট WiFi উভয় পরিবেশের জন্য সুরক্ষিত অথেন্টিকেশন ফ্লো সমর্থন করে। RadSec কীভাবে আপনার নির্দিষ্ট মোতায়েনে উপযুক্ত হতে পারে তা যদি আপনি বুঝতে চান, তবে Purple টিম আপনাকে এটি বিস্তারিতভাবে দেখাতে পারে। শোনার জন্য ধন্যবাদ। পরবর্তী সময় পর্যন্ত ভালো থাকবেন। - - - স্ক্রিপ্ট সমাপ্ত