RadSec: কীভাবে RADIUS over TLS WiFi অথেন্টিকেশন সিকিউরিটি উন্নত করে

RadSec: কীভাবে RADIUS over TLS WiFi অথেন্টিকেশন সিকিউরিটি উন্নত করে একটি Purple এন্টারপ্রাইজ WiFi ইন্টেলিজেন্স ব্রিফিং আনুমানিক রানটাইম: ১০ মিনিট --- [ভূমিকা এবং প্রেক্ষাপট — আনুমানিক ১ মিনিট] Purple এন্টারপ্রাইজ WiFi ইন্টেলিজেন্স সিরিজে আপনাকে স্বাগতম। আমি আপনাদের হোস্ট, এবং আজ আমরা এমন একটি বিষয় নিয়ে আলোচনা করছি যা নেটওয়ার্ক সিকিউরিটি এবং অপারেশনাল ঝুঁকির ঠিক সংযোগস্থলে অবস্থিত: RadSec — যা আনুষ্ঠানিকভাবে RFC 6614-এ সংজ্ঞায়িত — এবং কেন এটি আপনার ইনফ্রাস্ট্রাকচার রোডম্যাপে থাকা উচিত যদি তা ইতোমধ্যে না থাকে। আপনি যদি একজন আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট, বা CTO হন যিনি কোনো হোটেল গ্রুপ, রিটেইল এস্টেট, স্টেডিয়াম, বা পাবলিক-সেক্টর ক্যাম্পাস জুড়ে এন্টারপ্রাইজ WiFi-এর জন্য দায়ী, তবে এই ব্রিফিংটি আপনার জন্য। আমরা কভার করতে যাচ্ছি RadSec আসলে কী, কেন ঐতিহ্যবাহী RADIUS প্রোটোকল আপনাকে অরক্ষিত রাখে, কীভাবে একটি বাস্তব পরিবেশে RadSec ডিপ্লয় করতে হয় এবং কোন ফাঁদগুলো টিমগুলোকে বিপদে ফেলে। কেবল তত্ত্বের জন্য কোনো তত্ত্ব নয় — এই ত্রৈমাসিকে সিদ্ধান্ত নেওয়ার জন্য আপনার ঠিক যে তথ্যগুলো প্রয়োজন, শুধু সেগুলোই থাকবে। চলুন শুরু করা যাক। --- [টেকনিক্যাল ডিপ-ডাইভ — আনুমানিক ৫ মিনিট] তাহলে, চলুন সমস্যাটি দিয়ে শুরু করা যাক। RADIUS — রিমোট অথেন্টিকেশন ডায়াল-ইন ইউজার সার্ভিস — ১৯৯০-এর দশক থেকে এন্টারপ্রাইজ WiFi অথেন্টিকেশনের মেরুদণ্ড হিসেবে কাজ করছে। যখন কোনো ইউজার বা ডিভাইস আপনার কর্পোরেট বা গেস্ট WiFi-এর সাথে কানেক্ট করে, তখন অ্যাক্সেস পয়েন্ট একটি RADIUS ক্লায়েন্ট হিসেবে কাজ করে, অথেন্টিকেশন রিকোয়েস্টগুলো একটি RADIUS সার্ভারে ফরোয়ার্ড করে, যা আপনার ডিরেক্টরির — অ্যাক্টিভ ডিরেক্টরি, LDAP, বা একটি ক্লাউড আইডেন্টিটি প্রোভাইডার — বিপরীতে ক্রেডেনশিয়াল যাচাই করে এবং অ্যাক্সেস অনুমোদন বা প্রত্যাখ্যান করে। এটি হলো 802.1X অথেন্টিকেশন মডেল যা WPA2-Enterprise এবং WPA3-Enterprise নেটওয়ার্কগুলোর ভিত্তি। সমস্যা হলো ঐতিহ্যবাহী RADIUS একটি ভিন্ন যুগের জন্য ডিজাইন করা হয়েছিল। এটি UDP — ইউজার ডেটাগ্রাম প্রোটোকল — এর ওপর পোর্ট 1812 এবং 1813-এ চলে। UDP হলো কানেকশনলেস, যার মানে হলো এতে কোনো হ্যান্ডশেক নেই, কোনো সেশন স্টেট নেই এবং সবচেয়ে গুরুত্বপূর্ণ, কোনো নেটিভ এনক্রিপশন নেই। আপনার অ্যাক্সেস পয়েন্ট এবং আপনার RADIUS সার্ভারের মধ্যে একমাত্র সুরক্ষা হলো একটি শেয়ার্ড সিক্রেট — মূলত একটি পাসওয়ার্ড — যা MD5 হ্যাশিং ব্যবহার করে ট্রানজিটে ইউজারের পাসওয়ার্ড অস্পষ্ট করতে ব্যবহৃত হয়। MD5, যেমনটা আপনারা অনেকেই জানেন, ক্রিপ্টোগ্রাফিকভাবে দুর্বল। এটি বছরের পর বছর ধরে দুর্বল হয়ে আছে। বাস্তবে এর অর্থ কী? এর অর্থ হলো যে কোনো নেটওয়ার্ক সেগমেন্টে যেখানে একজন আক্রমণকারী RADIUS ট্রাফিক ইন্টারসেপ্ট করতে পারে — এবং এর মধ্যে রয়েছে কম্প্রোমাইজড সুইচ, আপনার ম্যানেজমেন্ট VLAN-এ থাকা রোগ ডিভাইস, বা একটি রিমোট অ্যাক্সেস পয়েন্ট এবং একটি ক্লাউড-হোস্টেড RADIUS সার্ভারের মধ্যবর্তী যেকোনো পয়েন্ট — তারা সম্ভাব্যভাবে অথেন্টিকেশন এক্সচেঞ্জ ক্যাপচার করতে পারে, শেয়ার্ড সিক্রেটের বিরুদ্ধে অফলাইন ডিকশনারি অ্যাটাকের চেষ্টা করতে পারে এবং কিছু কনফিগারেশনে, ইউজার ক্রেডেনশিয়ালগুলো সম্পূর্ণভাবে উন্মোচিত করতে পারে। ২০০টি প্রপার্টি জুড়ে গেস্ট WiFi চালানো একটি হোটেল গ্রুপ, বা পাবলিক ইন্টারনেটের মাধ্যমে একটি সেন্ট্রাল RADIUS সার্ভারে ব্যাকহলিং করা প্রতিটি স্টোরে অ্যাক্সেস পয়েন্ট থাকা একটি রিটেইল চেইনের জন্য, এটি কোনো তাত্ত্বিক ঝুঁকি নয়। এটি একটি লাইভ অ্যাটাক সারফেস। RadSec ঠিক এই সমস্যাটিই সমাধান করে। RadSec — RFC 6614-এ সংজ্ঞায়িত এবং RFC 7360 দ্বারা আপডেট করা — RADIUS ট্রাফিককে একটি TLS টানেলের ভেতরে র‍্যাপ করে। UDP-এর পরিবর্তে, এটি পোর্ট 2083-এ 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 সাপোর্ট করে না, যা উইন্ডোজ-কেন্দ্রিক ইনফ্রাস্ট্রাকচার চালানো প্রতিষ্ঠানগুলোর জন্য একটি উল্লেখযোগ্য সীমাবদ্ধতা। Cisco ISE RadSec সাপোর্ট করে। Aruba ClearPass RadSec সাপোর্ট করে। যদি আপনার RADIUS সার্ভার এবং আপনার অ্যাক্সেস পয়েন্ট ভেন্ডর উভয়ই নেটিভভাবে RadSec সাপোর্ট করে, তবে এটি সবচেয়ে পরিচ্ছন্ন পথ — উভয় প্রান্তে TLS সার্টিফিকেট কনফিগার করুন, আপনার ফায়ারওয়ালে TCP 2083 খুলুন এবং আপনি এন্ড-টু-এন্ড RADIUS ট্রাফিক এনক্রিপ্ট করছেন। দ্বিতীয় প্যাটার্নটি হলো একটি RadSec প্রক্সি। এটি বাস্তবে আরও সাধারণ ডিপ্লয়মেন্ট, বিশেষ করে লিগ্যাসি RADIUS ইনফ্রাস্ট্রাকচার বা মিক্সড-ভেন্ডর পরিবেশ থাকা প্রতিষ্ঠানগুলোর জন্য। একটি RadSec প্রক্সি — radsecproxy হলো সবচেয়ে ব্যাপকভাবে ডিপ্লয় করা ওপেন-সোর্স ইমপ্লিমেন্টেশন — আপনার অ্যাক্সেস পয়েন্ট এবং আপনার RADIUS সার্ভারের মধ্যে বসে। অ্যাক্সেস পয়েন্টগুলো লোকাল নেটওয়ার্কে প্রক্সিতে UDP-এর ওপর স্ট্যান্ডার্ড RADIUS পাঠায়। প্রক্সি সেই কানেকশনটি টার্মিনেট করে, একটি TLS টানেলের ভেতরে RADIUS ট্রাফিকটিকে পুনরায় এনক্যাপসুলেট করে এবং TCP 2083-এর মাধ্যমে আপস্ট্রিম RADIUS সার্ভারে ফরোয়ার্ড করে। এই পদ্ধতিটি আপনাকে আপনার RADIUS সার্ভার প্রতিস্থাপন না করেই একটি বিদ্যমান ইনফ্রাস্ট্রাকচারে RadSec যোগ করার সুবিধা দেয় এবং এটি বিশেষত তখন কার্যকর যখন আপনার RADIUS সার্ভার ক্লাউডে হোস্ট করা থাকে বা পাবলিক ইন্টারনেটের মাধ্যমে অ্যাক্সেস করা হয়। সার্টিফিকেট ম্যানেজমেন্ট হলো সেই অপারেশনাল জটিলতা যার জন্য আপনাকে পরিকল্পনা করতে হবে। মিউচুয়াল TLS-এর জন্য ব্যবহৃত X.509 সার্টিফিকেটগুলো ইস্যু এবং ম্যানেজ করার জন্য আপনার একটি PKI — পাবলিক কি ইনফ্রাস্ট্রাকচার — প্রয়োজন হবে। এর মানে হলো একটি সার্টিফিকেট অথরিটি, প্রতিটি RADIUS ক্লায়েন্ট এবং সার্ভারের জন্য সার্টিফিকেট ইস্যু করা এবং মেয়াদ শেষ হওয়ার আগে সার্টিফিকেট রোটেশনের জন্য একটি প্রক্রিয়া। অলক্ষ্যে মেয়াদ শেষ হওয়া সার্টিফিকেটগুলো আপনার নেটওয়ার্কের প্রতিটি ইউজারের জন্য একই সাথে অথেন্টিকেশন ব্রেক করবে — এবং এটি এমন একটি পরিস্থিতি যা আপনি এড়াতে চাইবেন। ACME বা আপনার CA-এর API ব্যবহার করে সার্টিফিকেট রিনিউয়াল অটোমেট করুন এবং মেয়াদ শেষ হওয়ার তারিখের অনেক আগেই মনিটরিং অ্যালার্ট সেট করুন। --- [ইমপ্লিমেন্টেশন সুপারিশ এবং ফাঁদ — আনুমানিক ২ মিনিট] আপনাদের কিছু ব্যবহারিক সুপারিশ দিচ্ছি। প্রথমত: ডিপ্লয় করার আগে অডিট করুন। আপনার পরিবেশের প্রতিটি RADIUS ক্লায়েন্ট — অ্যাক্সেস পয়েন্ট, VPN কনসেন্ট্রেটর, 802.1X করা সুইচ — এবং প্রতিটি RADIUS সার্ভার ম্যাপ করুন। বুঝুন কোনগুলো নেটিভভাবে RadSec সাপোর্ট করে এবং কোনগুলোর জন্য একটি প্রক্সি প্রয়োজন হবে। এই অডিটটি সাধারণত এমন লিগ্যাসি ডিভাইসগুলোকে সামনে নিয়ে আসে যেগুলো একেবারেই TLS সাপোর্ট করে না এবং সেগুলোকে আপনার রিপ্লেসমেন্ট রোডম্যাপে রাখতে হবে। দ্বিতীয়ত: সর্বোচ্চ-ঝুঁকিপূর্ণ ট্রাফিক দিয়ে শুরু করুন। যদি আপনার RADIUS ট্রাফিক পাবলিক ইন্টারনেট অতিক্রম করে — রিমোট সাইট, ক্লাউড-হোস্টেড RADIUS, মাল্টি-প্রপার্টি হোটেল গ্রুপ — তবে সেটি আপনার প্রথম অগ্রাধিকার। একটি সু-সেগমেন্টেড ম্যানেজমেন্ট VLAN-এ লোকাল RADIUS ট্রাফিক কম ঝুঁকিপূর্ণ, তবে এটিও রোডম্যাপে থাকা উচিত। তৃতীয়ত: গো-লাইভের আগে মিউচুয়াল TLS পুঙ্খানুপুঙ্খভাবে পরীক্ষা করুন। RadSec ডিপ্লয়মেন্টে সবচেয়ে সাধারণ ব্যর্থতার কারণ হলো সার্টিফিকেট ভ্যালিডেশন এরর — অমিল কমন নেম, মেয়াদোত্তীর্ণ ইন্টারমিডিয়েট সার্টিফিকেট, বা ক্লায়েন্টরা সার্ভার সার্টিফিকেট সাইন করা 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-এর কিছু কানেকশনলেস বৈশিষ্ট্য বজায় রাখে। এটি RadSec over TLS-এর তুলনায় কম ব্যাপকভাবে ডিপ্লয় করা হয় তবে হাই-থ্রুপুট পরিবেশে ল্যাটেন্সি নিয়ে উদ্বেগ থাকলে এটি মূল্যায়ন করার মতো। "এটি কীভাবে রোমিং পারফরম্যান্সকে প্রভাবিত করে?" RadSec-এর TCP কানেকশন পারসিস্টেন্ট, যা পরবর্তী অথেন্টিকেশন রিকোয়েস্টগুলোর জন্য কানেকশন সেটআপ ওভারহেড কমিয়ে ফেডারেটেড পরিবেশে রোমিং পারফরম্যান্স আসলে উন্নত করতে পারে। --- [সারসংক্ষেপ এবং পরবর্তী পদক্ষেপ — আনুমানিক ১ মিনিট] পরিশেষে: RadSec হলো ঐতিহ্যবাহী RADIUS-এর একটি প্রকৃত সিকিউরিটি গ্যাপের পরিণত, স্ট্যান্ডার্ড-ভিত্তিক উত্তর। আপনি যদি স্কেলে এন্টারপ্রাইজ WiFi চালান — একাধিক সাইট জুড়ে, ইন্টারনেটের ওপর, বা PCI DSS বা GDPR-এর অধীনস্থ পরিবেশে — তবে প্রশ্ন এটি নয় যে RadSec ডিপ্লয় করবেন কি না, প্রশ্ন হলো কখন এবং কীভাবে। আপনার পরবর্তী পদক্ষেপ: এই সপ্তাহে আপনার RADIUS ইনফ্রাস্ট্রাকচার অডিট করুন। আপনার সর্বোচ্চ-ঝুঁকিপূর্ণ ট্রাফিক ফ্লো চিহ্নিত করুন। নেটিভ RadSec সাপোর্টের জন্য আপনার RADIUS সার্ভার এবং অ্যাক্সেস পয়েন্ট ভেন্ডর ডকুমেন্টেশন চেক করুন। আপনি যদি FreeRADIUS চালান, তবে আপনি একদিনের মধ্যেই একটি টেস্ট RadSec ডিপ্লয়মেন্ট চালু করতে পারেন। আপনি যদি Microsoft NPS-এ থাকেন, তবে একটি প্রক্সি বা একটি RadSec-সক্ষম সার্ভারে মাইগ্রেশন পাথ মূল্যায়ন করা শুরু করুন। Purple-এর প্ল্যাটফর্ম এন্টারপ্রাইজ RADIUS ইনফ্রাস্ট্রাকচারের সাথে ইন্টিগ্রেট করার জন্য ডিজাইন করা হয়েছে, যা কর্পোরেট এবং গেস্ট WiFi উভয় পরিবেশের জন্যই সুরক্ষিত অথেন্টিকেশন ফ্লো সাপোর্ট করে। আপনি যদি বুঝতে চান যে RadSec কীভাবে আপনার নির্দিষ্ট ডিপ্লয়মেন্টের সাথে খাপ খায়, তবে Purple টিম আপনাকে এটি বুঝিয়ে বলতে পারে। শোনার জন্য ধন্যবাদ। আগামী পর্ব পর্যন্ত বিদায়। --- স্ক্রিপ্ট সমাপ্ত