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

RadSec: কীভাবে RADIUS over TLS WiFi অথেন্টিকেশন সিকিউরিটি উন্নত করে একটি Purple এন্টারপ্রাইজ WiFi ইন্টেলিজেন্স ব্রিফিং আনুমানিক সময়: ১০ মিনিট --- [ভূমিকা ও প্রেক্ষাপট — আনুমানিক ১ মিনিট] Purple এন্টারপ্রাইজ WiFi ইন্টেলিজেন্স সিরিজে আপনাকে স্বাগতম। আমি আপনার হোস্ট, এবং আজ আমরা এমন একটি বিষয় নিয়ে আলোচনা করছি যা নেটওয়ার্ক সিকিউরিটি এবং অপারেশনাল রিস্কের ঠিক মাঝখানে অবস্থান করে: RadSec — যা আনুষ্ঠানিকভাবে RFC 6614-এ সংজ্ঞায়িত করা হয়েছে — এবং কেন এটি ইতিমধ্যে আপনার ইনফ্রাস্ট্রাকচার রোডম্যাপে না থাকলে এখনই যুক্ত করা উচিত। আপনি যদি কোনো হোটেল গ্রুপ, রিটেইল এস্টেট, স্টেডিয়াম বা পাবলিক-সেক্টর ক্যাম্পাসে এন্টারপ্রাইজ WiFi-এর দায়িত্বে থাকা একজন IT ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট বা CTO হন, তবে এই ব্রিফিংটি আপনার জন্য। আমরা আলোচনা করব RadSec আসলে কী, কেন প্রথাগত RADIUS প্রোটোকল আপনাকে ঝুঁকির মুখে ফেলে, কীভাবে বাস্তব পরিবেশে RadSec ডেপ্লয় করতে হয় এবং কোন ভুলগুলোর কারণে টিমগুলো সমস্যায় পড়ে। শুধু তাত্ত্বিক কথা নয় — এই কোয়ার্টারে সিদ্ধান্ত নেওয়ার জন্য আপনার প্রয়োজনীয় তথ্যগুলোই আমরা তুলে ধরব। চলুন শুরু করা যাক। --- [টেকনিক্যাল ডিপ-ডাইভ — আনুমানিক ৫ মিনিট] তাহলে, সমস্যাটি দিয়ে শুরু করা যাক। RADIUS — রিমোট অথেন্টিকেশন ডায়াল-ইন ইউজার সার্ভিস — ১৯৯০-এর দশক থেকে এন্টারপ্রাইজ WiFi অথেন্টিকেশনের মেরুদণ্ড হিসেবে কাজ করে আসছে। যখন কোনো ব্যবহারকারী বা ডিভাইস আপনার কর্পোরেট বা গেস্ট WiFi-এর সাথে সংযুক্ত হয়, তখন অ্যাক্সেস পয়েন্টটি একটি RADIUS ক্লায়েন্ট হিসেবে কাজ করে, অথেন্টিকেশন রিকোয়েস্টগুলো একটি RADIUS সার্ভারে ফরোয়ার্ড করে, যা আপনার ডিরেক্টরি — Active Directory, LDAP বা কোনো ক্লাউড আইডেন্টিটি প্রোভাইডারের বিপরীতে ক্রেডেনশিয়াল যাচাই করে — এবং অ্যাক্সেস মঞ্জুর বা প্রত্যাখ্যান করে। এটি হলো 802.1X অথেন্টিকেশন মডেল যা WPA2-Enterprise এবং WPA3-Enterprise নেটওয়ার্কগুলোর ভিত্তি। সমস্যা হলো প্রথাগত RADIUS একটি ভিন্ন যুগের জন্য ডিজাইন করা হয়েছিল। এটি পোর্ট ১৮১২ এবং ১৮১৩-এ UDP — ইউজার ডেটাগ্রাম প্রোটোকল — এর ওপর চলে। UDP হলো কানেকশনলেস, যার মানে কোনো হ্যান্ডশেক নেই, কোনো সেশন স্টেট নেই এবং সবচেয়ে গুরুত্বপূর্ণভাবে, কোনো নেটিভ এনক্রিপশন নেই। আপনার অ্যাক্সেস পয়েন্ট এবং RADIUS সার্ভারের মধ্যে একমাত্র সুরক্ষা হলো একটি শেয়ার্ড সিক্রেট — মূলত একটি পাসওয়ার্ড — যা MD5 হ্যাশিং ব্যবহার করে ট্রানজিটে ব্যবহারকারীর পাসওয়ার্ডকে অস্পষ্ট করতে ব্যবহৃত হয়। আপনারা অনেকেই হয়তো জানেন, MD5 ক্রিপ্টোগ্রাফিকভাবে ভেঙে পড়েছে। এটি বছরের পর বছর ধরে অকার্যকর। বাস্তবে এর অর্থ কী? এর অর্থ হলো নেটওয়ার্কের যেকোনো অংশে যেখানে কোনো আক্রমণকারী RADIUS ট্রাফিক ইন্টারসেপ্ট করতে পারে — যার মধ্যে রয়েছে হ্যাক হওয়া সুইচ, আপনার ম্যানেজমেন্ট VLAN-এর রোগ (rogue) ডিভাইস, অথবা একটি রিমোট অ্যাক্সেস পয়েন্ট এবং ক্লাউড-হোস্টেড RADIUS সার্ভারের মধ্যবর্তী যেকোনো পয়েন্ট — তারা সম্ভাব্যভাবে অথেন্টিকেশন এক্সচেঞ্জগুলো ক্যাপচার করতে পারে, শেয়ার্ড সিক্রেটের বিরুদ্ধে অফলাইন ডিকশনারি অ্যাটাকের চেষ্টা করতে পারে এবং কিছু কনফিগারেশনে ব্যবহারকারীর ক্রেডেনশিয়াল সম্পূর্ণরূপে উন্মুক্ত করে দিতে পারে। ২০০টি প্রপার্টি জুড়ে গেস্ট WiFi চালানো একটি হোটেল গ্রুপ, অথবা প্রতিটি স্টোরে অ্যাক্সেস পয়েন্ট থাকা একটি রিটেইল চেইনের জন্য যা পাবলিক ইন্টারনেটের মাধ্যমে একটি সেন্ট্রাল RADIUS সার্ভারে ব্যাকহল করে, এটি কোনো তাত্ত্বিক ঝুঁকি নয়। এটি একটি সক্রিয় অ্যাটাক সারফেস। RadSec ঠিক এই সমস্যাটিই সমাধান করে। RadSec — যা RFC 6614-এ সংজ্ঞায়িত এবং RFC 7360 দ্বারা আপডেট করা হয়েছে — RADIUS ট্রাফিককে একটি TLS টানেলের মধ্যে মুড়িয়ে দেয়। 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 ২০৮৩ পোর্ট খুলুন এবং আপনি এন্ড-টু-এন্ড RADIUS ট্রাফিক এনক্রিপ্ট করতে পারবেন। দ্বিতীয় প্যাটার্নটি হলো একটি RadSec প্রক্সি। এটি বাস্তবে সবচেয়ে সাধারণ ডেপ্লয়মেন্ট, বিশেষ করে লেগাসি RADIUS ইনফ্রাস্ট্রাকচার বা মিশ্র-ভেন্ডর পরিবেশের সংস্থাগুলোর জন্য। একটি RadSec প্রক্সি — radsecproxy হলো সবচেয়ে বহুল ব্যবহৃত ওপেন-সোর্স ইমপ্লিমেন্টেশন — আপনার অ্যাক্সেস পয়েন্ট এবং RADIUS সার্ভারের মধ্যে অবস্থান করে। অ্যাক্সেস পয়েন্টগুলো লোকাল নেটওয়ার্কে প্রক্সির কাছে UDP-এর মাধ্যমে স্ট্যান্ডার্ড RADIUS পাঠায়। প্রক্সি সেই কানেকশনটি বন্ধ করে, RADIUS ট্রাফিককে একটি TLS টানেলের মধ্যে পুনরায় এনক্যাপসুলেট করে এবং TCP ২০৮৩-এর মাধ্যমে আপস্ট্রিম 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 ২০৮৩ খোলা থাকা প্রয়োজন। আপনি যদি UDP ১৮১২ নিয়মগুলো পরিচালনায় অভ্যস্ত হন, তবে ফায়ারওয়াল পরিবর্তন প্রক্রিয়ায় TCP ২০৮৩ বাদ পড়ে যেতে পারে। --- [র‌্যাপিড-ফায়ার প্রশ্নোত্তর — আনুমানিক ১ মিনিট] আমি নিয়মিত শুনতে পাই এমন কয়েকটি প্রশ্ন সংক্ষেপে আলোচনা করি। "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 টিম আপনাকে এটি বুঝতে সাহায্য করতে পারে। শোনার জন্য ধন্যবাদ। পরবর্তী সময় পর্যন্ত বিদায়। --- স্ক্রিপ্ট সমাপ্ত