কেন আমার গেস্ট WiFi কানেক্ট হচ্ছে না? captive portal-এর সমস্যা সমাধান করা

TITLE: Why Is My Guest WiFi Not Connecting? Troubleshooting Captive Portal Issues FORMAT: Purple Technical Briefing Podcast VOICE: UK English - Senior Solutions Architect tone DURATION: Approximately 10 minutes --- SECTION 1: Introduction and Context - approximately 1 minute হ্যালো এবং Purple-এর এই টেকনিক্যাল ব্রিফিংয়ে আপনাকে স্বাগতম। আমি আপনার হোস্ট, এবং আজ আমরা এন্টারপ্রাইজ ওয়্যারলেস নেটওয়ার্কিংয়ের সবচেয়ে স্থায়ী ও ভুল বোঝাবুঝি হওয়া সমস্যাগুলোর একটির সমাধান করব: গেস্ট WiFi captive portal যা লোড হতে একেবারেই অস্বীকৃতি জানায়। আপনি এমন পরিস্থিতিতে পড়েছেন। একজন গেস্ট আপনার হোটেল, রিটেইল স্টোর, স্টেডিয়াম বা কনফারেন্স সেন্টারে এলেন। তারা WiFi নেটওয়ার্কে যুক্ত হলেন। কিন্তু কিছুই হলো না। কোনো লগইন পেজ নেই। কোনো ইন্টারনেট নেই। কেবল একটি স্পিনিং আইকন এবং ক্রমাগত বাড়তে থাকা বিরক্তি। ভেন্যু অপারেশন ডিরেক্টর এবং IT ম্যানেজারদের জন্য, সেই মুহূর্তটি কেবল সামান্য একটি অসুবিধা নয়। এটি আপনার গেস্ট এক্সপেরিয়েন্সের সরাসরি ব্যর্থতা, ফ্রন্ট-অফ-হাউস সাপোর্ট কলের আকস্মিক বৃদ্ধি এবং আপনার ওয়্যারলেস ইনফ্রাস্ট্রাকচার ইনভেস্টমেন্টকে যৌক্তিক প্রমাণ করার জন্য প্রয়োজনীয় ফার্স্ট-পার্টি ডেটা সংগ্রহ করার একটি হাতছাড়া সুযোগ। এই ব্রিফিংয়ে, আমরা এর গভীরে যাব। আমরা ব্যাখ্যা করব অপারেটিং সিস্টেম স্তরে captive portal ডিটেকশন ঠিক কীভাবে কাজ করে, সংযোগ ব্যর্থতার সিংহভাগের জন্য দায়ী ছয়টি মূল কারণ চিহ্নিত করব এবং আপনাকে একটি ব্যবহারিক ও কার্যকর ট্রাবলশুটিং ফ্রেমওয়ার্ক দেব যা আপনি আজই আপনার IT টিমকে হস্তান্তর করতে পারবেন। চলুন শুরু করা যাক। --- SECTION 2: Technical Deep-Dive - approximately 5 minutes একটি captive portal সমস্যার সমাধান করতে, আপনাকে প্রথমে বুঝতে হবে নেটওয়ার্ক স্তরে একটি captive portal আসলে কী কাজ করে। বেশিরভাগ মানুষ এটিকে কেবল একটি সাধারণ লগইন পেজ মনে করেন। এটি আসলে একটি নেটওয়ার্ক-লেভেল ট্রাফিক ইন্টারসেপশন মেকানিজম, এবং যখন কিছু ভুল হয়ে যায় তখন এই পার্থক্যটি অত্যন্ত গুরুত্ব বহন করে। প্রক্রিয়াটি এইরকম। একজন গেস্টের ডিভাইস আপনার গেস্ট SSID-এ যুক্ত হয় এবং DHCP-এর মাধ্যমে একটি IP অ্যাড্রেস লাভ করে। সেই মুহূর্তে, অপারেটিং সিস্টেম ব্যবহারকারীর ব্রাউজার ওপেন করার জন্য অপেক্ষা করে না। ব্যাকগ্রাউন্ডে, একটি সিস্টেম সার্ভিস সাথে সাথে একটি ভেন্ডর-নিয়ন্ত্রিত প্রোব URL-এ একটি আনএনক্রিপ্টেড HTTP GET রিকোয়েস্ট পাঠায়। Apple ডিভাইসগুলো captive.apple.com-এ কোয়েরি পাঠায়। Android ডিভাইসগুলো connectivitycheck.gstatic.com-এ কোয়েরি পাঠায়। Windows ডিভাইসগুলো msftconnecttest.com-এ কোয়েরি পাঠায়। Firefox-এর detectportal.firefox.com-এ নিজস্ব প্রোব রয়েছে। নেটওয়ার্কে যদি উন্মুক্ত ইন্টারনেট অ্যাক্সেস থাকে, তবে এই প্রোবগুলো তাদের প্রত্যাশিত রেসপন্স ফেরত দেয় এবং অপারেটিং সিস্টেম সিদ্ধান্ত নেয় যে সবকিছু ঠিক আছে। কিন্তু একটি গেস্ট নেটওয়ার্কে, আপনার ওয়্যারলেস গেটওয়ে বা কন্ট্রোলার সেই HTTP প্রোবটি ইন্টারনেটে পৌঁছানোর আগেই সেটিকে ইন্টারসেপ্ট বা বাধা প্রদান করে। প্রত্যাশিত রেসপন্সের পরিবর্তে, গেটওয়েটি একটি HTTP 302 রিডাইরেক্ট পাঠায় যা আপনার captive portal স্প্ল্যাশ পেজের দিকে নির্দেশ করে। অপারেটিং সিস্টেম এই অপ্রত্যাশিত রিডাইরেক্টটি সনাক্ত করে, বুঝতে পারে যে এটি একটি captive portal-এর অধীনে রয়েছে এবং লগইন পেজটি প্রদর্শন করার জন্য একটি স্যান্ডবক্সড ব্রাউজার উইন্ডো - যা প্রায়শই Captive Portal Assistant নামে পরিচিত - ওপেন করে। এটি হলো স্বাভাবিক ও সফল প্রক্রিয়া। এবার চলুন আলোচনা করা যাক সেই ছয়টি বিষয় নিয়ে যার কারণে এটি ব্যর্থ হয়।মূল কারণ নম্বর এক: DHCP পুল নিঃশেষ হওয়া। উচ্চ-ঘনত্বের ইভেন্টগুলিতে এটি একটি নীরব ঘাতক। আপনি যদি একটি স্ট্যান্ডার্ড স্ল্যাশ-২৪ সাবনেটে দুই হাজার অংশগ্রহণকারী নিয়ে একটি সম্মেলন পরিচালনা করেন, তবে আপনার কাছে ২৫৪টি ব্যবহারযোগ্য IP অ্যাড্রেস রয়েছে। আপনার DHCP লিজ টাইম যদি ডিফল্ট ২৪ ঘণ্টায় সেট করা থাকে, তবে দরজা খোলার কয়েক মিনিটের মধ্যেই আপনার সেই পুলটি নিঃশেষ হয়ে যাবে। ক্যাপটিভ পোর্টাল সিকোয়েন্স শুরু হওয়ার আগেই পরবর্তী প্রতিটি সংযোগের চেষ্টা ব্যর্থ হয়। এর সমাধান সহজ: উচ্চ-টার্নওভার পরিবেশের জন্য গেস্ট DHCP লিজ টাইম ১৫ থেকে ৩০ মিনিটের মধ্যে সেট করুন এবং শুধুমাত্র মোট হেডকাউন্টের জন্য নয়, বরং পিক কনকারেন্ট ব্যবহারকারীদের জন্য আপনার সাবনেটগুলি যথাযথভাবে আকার দিন। মূল কারণ নম্বর দুই: DNS ইন্টারসেপশন ব্যর্থতা। ক্যাপটিভ পোর্টাল রিডাইরেক্ট গেটওয়ে দ্বারা HTTP প্রোব ইন্টারসেপ্ট করার উপর নির্ভর করে। কিন্তু প্রোবের জন্য প্রথমে একটি DNS লুকআপের প্রয়োজন হয়। আপনার DNS কনফিগারেশন যদি প্রি-অথেন্টিকেটেড ক্লায়েন্টদের এক্সটার্নাল ডোমেন নামগুলি রিসলভ করার অনুমতি না দেয়, তবে প্রোবটি কখনোই ফায়ার হয় না। আপনার ফায়ারওয়াল পলিসি যেন স্পষ্টভাবে আনঅথেন্টিকেটেড ক্লায়েন্টদের থেকে DNS কুয়েরির অনুমতি দেয় তা নিশ্চিত করুন এবং একটি টেস্ট ডিভাইসের বিরুদ্ধে প্যাকেট ক্যাপচার রান করে আপনার DNS ইন্টারসেপশন কাজ করছে কিনা তা যাচাই করুন। মূল কারণ নম্বর তিন: অসম্পূর্ণ ওয়াল্ড গার্ডেন। ওয়াল্ড গার্ডেন - যাকে প্রি-অথরাইজেশন অ্যাক্সেস কন্ট্রোল লিস্টও বলা হয় - এটি নির্ধারণ করে যে আনঅথেন্টিকেটেড গেস্টরা কোন এক্সটার্নাল ডোমেনগুলিতে পৌঁছাতে পারবে। আপনার পোর্টাল স্প্ল্যাশ পেজটি যদি এমন কোনো CDN থেকে অ্যাসেট লোড করে যা ওয়াল্ড গার্ডেনে নেই, তবে পেজটি একটি ফাঁকা স্ক্রিন হিসেবে প্রদর্শিত হবে। আপনি যদি Google, Apple, বা Facebook-এর মাধ্যমে সোশ্যাল লগইন অফার করেন, তবে সেই প্রোভাইডারদের ব্যবহৃত প্রতিটি OAuth ডোমেন অবশ্যই হোয়াইটলিস্টেড হতে হবে। এবং এখানে একটি গুরুত্বপূর্ণ বিষয় রয়েছে: সোশ্যাল আইডেন্টিটি প্রোভাইডাররা নিয়মিত তাদের CDN IP রেঞ্জ এবং অথেন্টিকেশন ডোমেন আপডেট করে। ছয় মাস আগে যে ওয়াল্ড গার্ডেনটি নিখুঁতভাবে কাজ করেছিল তা আজ নীরবে ভেঙে যেতে পারে। ত্রৈমাসিক ওয়াল্ড গার্ডেন অডিট করার সময়সূচী নির্ধারণ করুন এবং যেখানে আপনার হার্ডওয়্যার এটি সাপোর্ট করে সেখানে ওয়াইল্ডকার্ড ডোমেন স্নুপিং ব্যবহার করুন। Cisco Meraki, HPE Aruba, Ruckus, এবং Juniper Mist-এ এটি নেটিভভাবে উপলব্ধ। মূল কারণ নম্বর চার: HSTS রিডাইরেক্ট ব্লক করছে। HTTP স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি, বা HSTS হলো একটি ব্রাউজার সিকিউরিটি পলিসি যা শুধুমাত্র HTTPS-এর মাধ্যমে নির্দিষ্ট ডোমেনগুলিতে সংযোগ স্থাপন করতে বাধ্য করে। যদি কোনো গেস্টের ডিভাইস একটি HSTS-প্রিলোডেড ডোমেনে - এবং এর মধ্যে কার্যত প্রতিটি বড় ওয়েবসাইট অন্তর্ভুক্ত রয়েছে - যোগাযোগ করার চেষ্টা করে এবং আপনার গেটওয়ে পোর্টালের দিকে রিডাইরেক্ট করতে সেই HTTPS রিকোয়েস্টটি ইন্টারসেপ্ট করার চেষ্টা করে, তবে ব্রাউজারটি একটি সার্টিফিকেট মিসম্যাচ সনাক্ত করে। এটি একটি নন-বাইপাসেবল সিকিউরিটি ওয়ার্নিং প্রদর্শন করে এবং রিডাইরেক্টটিকে সম্পূর্ণরূপে ব্লক করে। এর সঠিক সমাধান হলো কখনোই HTTPS ইন্টারসেপশনের চেষ্টা না করা। আপনার গেটওয়ে শুধুমাত্র আনএনক্রিপ্টেড HTTP ক্যানারি প্রোবগুলিকে রিডাইরেক্ট করা উচিত। দীর্ঘমেয়াদী স্ট্যান্ডার্ড-ভিত্তিক সমাধান হলো RFC 8910, যা DHCP Option 114 ডিফাইন করে। এই অপশনটি আপনার DHCP সার্ভারকে সরাসরি ক্লায়েন্ট ডিভাইসে ক্যাপটিভ পোর্টাল URL বিজ্ঞাপন করার অনুমতি দেয়, যার ফলে HTTP রিডাইরেকশনের প্রয়োজনীয়তা সম্পূর্ণ এড়ানো যায়। iOS 14 এবং Android 11 এবং তার পরবর্তী সংস্করণগুলি এটিকে নেটিভভাবে সাপোর্ট করে। মূল কারণ নম্বর পাঁচ: গেস্ট ডিভাইসে সক্রিয় VPN। একটি VPN ডিভাইস থেকে আসা সমস্ত ট্রাফিক এনক্রিপ্ট করে এবং আপনার গেটওয়েতে পৌঁছানোর আগে এটিকে একটি এক্সটার্নাল টানেলের মাধ্যমে রাউট করে। আপনার গেটওয়ে কখনই HTTP প্রোব দেখতে পায় না। Captive Portal ডিটেকশন সিকোয়েন্স কখনই ট্রিগার হয় না। গেস্ট কোনো লগইন পেজ বা ইন্টারনেট দেখতে পান না। গেস্টের জন্য সমাধানটি সহজ: VPN নিষ্ক্রিয় করুন, পোর্টালে কানেক্ট করুন, তারপর আবার VPN সক্রিয় করুন। গেস্ট যখন কোনো কানেকশন সমস্যার কথা জানান, তখন আপনার ফ্রন্ট-অফ-হাউস কর্মীদের জন্য এটিই হওয়া উচিত প্রথম জিজ্ঞাসা করা প্রশ্ন। মূল কারণ নম্বর ছয়: MAC অ্যাড্রেস র্যান্ডমাইজেশনের কারণে সেশন পারসিস্টেন্স নষ্ট হওয়া। আধুনিক iOS এবং Android ডিভাইসগুলো প্রাইভেসি ফিচার হিসেবে ডিফল্টভাবে র্যান্ডমাইজড MAC অ্যাড্রেস ব্যবহার করে। প্রতিবার কোনো ডিভাইস একটি নেটওয়ার্কের সাথে কানেক্ট করার সময় এটি একটি ভিন্ন MAC অ্যাড্রেস প্রদর্শন করতে পারে। যেহেতু Captive Portal সেশন স্টেট MAC অ্যাড্রেসের মাধ্যমে ট্র্যাক করা হয়, তাই এক ঘণ্টা আগে অথেন্টিকেট করা একজন গেস্টকে তার ডিভাইসের MAC পরিবর্তিত হওয়ার পর আবার লগইন পেজ দেখানো হতে পারে। গেস্ট-মুখী সমাধান হলো নেটওয়ার্ক সেটিংসে আপনার নির্দিষ্ট SSID-এর জন্য Private Address নিষ্ক্রিয় করা। অপারেটর-সাইড সমাধান হলো প্রোফাইল-ভিত্তিক অথেন্টিকেশন ইমপ্লিমেন্ট করা - যেমন Passpoint এবং 802.1X-এর মাধ্যমে OpenRoaming - যা MAC অ্যাড্রেসের পরিবর্তে ক্রেডেন্সিয়াল ব্যবহার করে লেয়ার ২-এ অথেন্টিকেট করে, যার ফলে র্যান্ডমাইজেশন আর কোনো প্রভাব ফেলে না। - - - সেকশন ৩: ইমপ্লিমেন্টেশন সংক্রান্ত সুপারিশ এবং সমস্যাসমূহ - আনুমানিক ২ মিনিট এখন যেহেতু আমরা মূল কারণগুলো বুঝতে পেরেছি, আসুন একটি সঠিকভাবে কনফিগার করা Captive Portal ডিপ্লয়মেন্ট আসলে কেমন দেখায় তা নিয়ে আলোচনা করা যাক। আপনার DHCP আর্কিটেকচার দিয়ে শুরু করুন। ২০০-এর বেশি সমসাময়িক ডিভাইস আশা করে এমন যেকোনো ভেন্যুর জন্য একটি সিঙ্গেল স্ল্যাশ-২৪ সাবনেট থেকে সরে আসুন। স্ল্যাশ-২২ বা তার চেয়ে বড় সাবনেট ব্যবহার করুন এবং আপনার ভেন্যুর ডোয়েল প্রোফাইলের সাথে মিলিয়ে লিজের সময় সেট করুন। একটি হোটেল ৮ ঘণ্টার জন্য লিজ সেট করে। একটি স্টেডিয়াম ৩ ঘণ্টার জন্য লিজ সেট করে। একটি শপিং সেন্টার ৯০ মিনিটের জন্য লিজ সেট করে। একটি কনফারেন্স সেন্টার ৩০ মিনিটের জন্য লিজ সেট করে। এরপরে, প্রতিটি বড় ইভেন্টের আগে আপনার ওয়াল্ড গার্ডেন (walled garden) যাচাই করুন। ন্যূনতম প্রয়োজনীয় এন্ট্রিগুলো হলো: আপনার পোর্টালের FQDN এবং সমস্ত সংশ্লিষ্ট CDN ডোমেন, Apple, Google, Windows এবং Firefox-এর জন্য Captive Portal ডিটেকশন URL এবং আপনার সাপোর্ট করা প্রতিটি সোশ্যাল লগইন প্রোভাইডারের জন্য OAuth ডোমেন। Purple-এর প্ল্যাটফর্মে, আমরা আমাদের ক্লাউড-ম্যানেজড সার্ভিসের অংশ হিসেবে এই ওয়াল্ড গার্ডেন এন্ট্রিগুলো স্বয়ংক্রিয়ভাবে বজায় রাখি এবং আপডেট করি, যা আপনার টিমের ম্যানুয়াল রক্ষণাবেক্ষণের ঝামেলা দূর করে। আপনার পোর্টাল সার্টিফিকেটের জন্য, একটি স্বীকৃত সার্টিফিকেট অথরিটি থেকে পাবলিকলি ট্রাস্টেড TLS সার্টিফিকেট ব্যবহার করুন। সেলফ-সাইনড সার্টিফিকেটগুলো প্রতিটি ডিভাইসে ব্রাউজার ওয়ার্নিং ট্রিগার করবে। মেয়াদ শেষ হওয়ার আগেই সার্টিফিকেট রিনিউ করুন - একটি মেয়াদোত্তীর্ণ সার্টিফিকেট হঠাৎ করে পুরো ভেন্যু জুড়ে পোর্টাল ব্যর্থতার অন্যতম সাধারণ কারণ। একটি সমস্যা যা অনেক IT টিমের ক্ষেত্রে ঘটে থাকে: পূর্বে প্রমাণীকরণ করা একটি ডিভাইস থেকে পোর্টালটি পরীক্ষা করা। আপনার ডিভাইসের সেশন এখনও সক্রিয় রয়েছে, তাই আপনি পোর্টালটিকে সম্পূর্ণরূপে বাইপাস করে চলে যান এবং সিদ্ধান্ত নেন যে সবকিছু কাজ করছে। সর্বদা একটি নতুন, অপ্রমাণিত অবস্থায় থাকা ডিভাইস থেকে পরীক্ষা করুন - হয় একটি নতুন ডিভাইস, অথবা এমন একটি যেখানে আপনি নেটওয়ার্কটি ভুলে গেছেন এবং WiFi প্রোফাইলটি মুছে ফেলেছেন। অবশেষে, যাত্রার কৌশলগত দিকটি বিবেচনা করুন। Captive portals একটি পরিপক্ক প্রযুক্তি, তবে তারা অন্তর্নিহিত ঘর্ষণ বহন করে। OpenRoaming, যা Passpoint এবং 802.1X এর উপর ভিত্তি করে তৈরি, ফিরে আসা অতিথিদের কোনো লগইন পৃষ্ঠা না দেখেই স্বয়ংক্রিয়ভাবে এবং নিরাপদে সংযুক্ত হতে দেয়। Purple আমাদের Connect প্ল্যানের অধীনে OpenRoaming এর জন্য একটি বিনামূল্যে পরিচয় প্রদানকারী হিসেবে কাজ করে। Premier Inn এবং Manchester Airports Group এর মতো ভেন্যুগুলো পুনরাবৃত্ত দর্শনার্থীদের জন্য পুনরায় প্রমাণীকরণের ঝামেলা দূর করতে ইতিমধ্যেই এটি স্থাপন করছে এবং একই সাথে সম্পূর্ণ GDPR সম্মতি এবং ফার্স্ট-পার্টি ডেটা সংগ্রহ বজায় রাখছে। - - - সেকশন ৪: দ্রুত প্রশ্নোত্তর - প্রায় ১ মিনিট আসুন আমরা ভেন্যু IT টিমের কাছ থেকে সবচেয়ে বেশি শোনা সাধারণ প্রশ্নগুলো একবার দেখে নেই। প্রশ্ন: কেন পোর্টালটি iPhones এ কাজ করে কিন্তু Android ডিভাইসে করে না? উত্তর: Android তার প্রোব URL হিসেবে connectivitycheck.gstatic.com ব্যবহার করে। যদি সেই ডোমেনটি আপনার ফায়ারওয়াল দ্বারা অবরুদ্ধ থাকে বা আপনার ওয়াল্ড গার্ডেনে না থাকে, তবে Android ডিভাইসগুলো কখনই পোর্টালটি ট্রিগার করে না। এটি স্পষ্টভাবে যোগ করুন। প্রশ্ন: একজন অতিথি বলেছেন যে পোর্টালটি লোড হয়েছে কিন্তু লগইন করার পরে তারা অনলাইন হতে পারছেন না। উত্তর: এটি প্রায় সবসময়ই একটি RADIUS অনুমোদন ব্যর্থতা। আপনার ওয়্যারলেস কন্ট্রোলার থেকে আপনার RADIUS সার্ভার অ্যাক্সেসযোগ্য কিনা তা পরীক্ষা করুন, উভয় পাশে শেয়ার্ড সিক্রেট মিলেছে কিনা তা যাচাই করুন এবং Access-Reject বার্তাগুলোর জন্য RADIUS লগগুলো পর্যালোচনা করুন। প্রশ্ন: কয়েক মিনিট পর পরই লগ আউট হয়ে যাওয়া অতিথিদের আমরা কীভাবে পরিচালনা করব? উত্তর: আপনার আইডল টাইমআউট সেটিং পরীক্ষা করুন। অনেক কন্ট্রোলারে ডিফল্টরূপে ৫ মিনিটের আইডল টাইমআউট থাকে, যা ইন্টারঅ্যাকশনের মাঝে স্লিপ মোডে চলে যাওয়া মোবাইল ডিভাইসের জন্য অত্যন্ত আক্রমণাত্মক। আতিথেয়তা এবং খুচরা বিক্রয় পরিবেশের জন্য আইডল টাইমআউট কমপক্ষে ৩০ মিনিট সেট করুন। - - - সেকশন ৫: সংক্ষিপ্তসার এবং পরবর্তী পদক্ষেপ - প্রায় ১ মিনিট সংক্ষেপে বলতে গেলে: গেস্ট WiFi captive portal ব্যর্থতা ছয়টি বিভাগে পড়ে - DHCP নিঃশেষকরণ, DNS ইন্টারসেপশন ব্যর্থতা, অপূর্ণাঙ্গ ওয়াল্ড গার্ডেন, HSTS রিডাইরেক্ট ব্লকিং, ক্লায়েন্ট ডিভাইসে সক্রিয় VPN এবং MAC অ্যাড্রেস র্যান্ডমাইজেশন। প্রতিটির একটি নির্দিষ্ট, পরীক্ষাযোগ্য সমাধান রয়েছে। আপনার IT টিমের জন্য, তাৎক্ষণিক পদক্ষেপগুলো হলো: আপনার DHCP লিজের সময় এবং সাবনেট সাইজিং অডিট করুন, আপনার সোশ্যাল লগইন প্রদানকারীদের বর্তমান OAuth ডোমেনের বিপরীতে আপনার ওয়াল্ড গার্ডেন যাচাই করুন এবং প্রতিটি কনফিগারেশন পরিবর্তনের পরে একটি নতুন অপ্রমাণিত ডিভাইস থেকে আপনার পোর্টালটি পরীক্ষা করুন। আপনার দীর্ঘমেয়াদী রোডম্যাপের জন্য, ফিরে আসা দর্শনার্থীদের জন্য captive portal পুনরায় প্রমাণীকরণের উত্তরসূরি হিসেবে OpenRoaming মূল্যায়ন করুন। প্রযুক্তিটি পরিপক্ক, মানগুলো IEEE 802.1X এবং WPA3-Enterprise এর অধীনে প্রতিষ্ঠিত এবং Purple এটিকে Connect প্ল্যানের অধীনে কোনো অতিরিক্ত সফটওয়্যার খরচ ছাড়াই উপলব্ধ করে।আরও টেকনিক্যাল গাইড, কেস স্টাডি এবং ইমপ্লিমেন্টেশন রিসোর্সের জন্য purple.ai ভিজিট করুন। এই Purple টেকনিক্যাল ব্রিফিংটি শোনার জন্য আপনাকে ধন্যবাদ। আপনার নেটওয়ার্কগুলোকে নির্ভরযোগ্য রাখুন এবং আপনার গেস্টদের কানেক্টেড রাখুন।