পাবলিক WiFi সমস্যার সমাধান: 'Connected, No Internet' এবং স্প্ল্যাশ পেজ রিডাইরেকশন ব্যর্থতা ঠিক করা

Purple-এর এই টেকনিক্যাল ব্রিফিং-এ আপনাকে স্বাগত। আজ আমরা এন্টারপ্রাইজ ওয়্যারলেস নেটওয়ার্কিংয়ের সবচেয়ে দীর্ঘস্থায়ী এবং সবচেয়ে ভুল বোঝা সমস্যাগুলির একটির সমাধান করছি: গেস্ট WiFi captive portal যা কোনোভাবেই লোড হতে চায় না। আপনিও এই পরিস্থিতির মুখোমুখি হয়েছেন। আপনার হোটেল, রিটেইল স্টোর, স্টেডিয়াম বা কনফারেন্স সেন্টারে কোনো গেস্ট এলেন। তারা WiFi নেটওয়ার্কে যুক্ত হলেন। কিন্তু কিছুই হলো না। কোনো লগইন পেজ নেই। ইন্টারনেট নেই। কেবল একটি স্পিনিং আইকন এবং ক্রমশ বাড়তে থাকা হতাশা। ভেন্যু অপারেশন ডিরেক্টর এবং IT ম্যানেজারদের জন্য, সেই মুহূর্তটি কেবল একটি ছোটখাটো অসুবিধা নয়। এটি আপনার গেস্ট অভিজ্ঞতার সরাসরি ব্যর্থতা, ফ্রন্ট-অফিস সাপোর্ট কলের সংখ্যা বৃদ্ধি এবং আপনার ওয়্যারলেস অবকাঠামো বিনিয়োগের যৌক্তিকতা প্রমাণকারী ফার্স্ট-পার্টি ডেটা সংগ্রহ করার একটি হাতছাড়া হওয়া সুযোগ। এই ব্রিফিংয়ে, আমরা এর অন্তর্নিহিত কৌশলগুলো নিয়ে আলোচনা করব। আমরা অবিকল ব্যাখ্যা করব কীভাবে অপারেটিং সিস্টেম স্তরে captive portal সনাক্তকরণ কাজ করে, বেশিরভাগ কানেকশন ব্যর্থতার জন্য দায়ী ছয়টি মূল কারণ চিহ্নিত করব এবং আপনাকে একটি ব্যবহারিক ও কার্যকর ট্রাবলশুটিং ফ্রেমওয়ার্ক দেব যা আপনি আজই আপনার IT টিমকে প্রদান করতে পারবেন। চলুন এর কার্যপদ্ধতি দিয়ে শুরু করা যাক। বেশিরভাগ মানুষ 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 307 রিডাইরেক্ট ফেরত পাঠায় যা আপনার captive portal স্প্ল্যাশ পেজের দিকে নির্দেশ করে। অপারেটিং সিস্টেমটি এই অপ্রত্যাশিত রিডাইরেক্ট সনাক্ত করে, বুঝতে পারে যে এটি একটি captive portal-এর অধীনে রয়েছে এবং লগইন পেজটি দেখানোর জন্য একটি স্যান্ডবক্সড ব্রাউজার উইন্ডো খোলে - যাকে প্রায়শই Captive Network Assistant বলা হয়। এটি হলো স্বাভাবিক ও সফল প্রক্রিয়া। এবার চলুন জেনে নেওয়া যাক যে ছয়টি উপায়ে এটি ব্যর্থ হতে পারে। মূল কারণ নম্বর এক: DHCP pool শেষ হয়ে যাওয়া। উচ্চ-ঘনত্বের ইভেন্টগুলিতে এটি একটি নীরব ঘাতক। আপনি যদি একটি স্ট্যান্ডার্ড স্ল্যাশ-২৪ সাবনেটে দুই হাজার জন অংশগ্রহণকারীর সাথে একটি কনফারেন্স পরিচালনা করেন, তবে আপনার কাছে ২৫৪টি ব্যবহারযোগ্য IP ঠিকানা রয়েছে। যদি আপনার DHCP লিজের সময় ডিফল্ট ২৪ ঘন্টা সেট করা থাকে, তবে দরজা খোলার কয়েক মিনিটের মধ্যেই আপনার সেই পুলটি শেষ হয়ে যাবে। এর পরবর্তী প্রতিটি সংযোগের চেষ্টা Captive Portal সিকোয়েন্স শুরু হওয়ার আগেই ব্যর্থ হবে। এর সমাধান সহজ: উচ্চ-টার্নওভার পরিবেশের জন্য গেস্ট DHCP লিজের সময় ১৫ থেকে ৩০ মিনিটের মধ্যে সেট করুন এবং শুধুমাত্র মোট headcount-এর জন্য নয়, বরং পিক সমসাময়িক ব্যবহারকারীদের জন্য আপনার সাবনেটগুলি সঠিকভাবে সাইজ করুন। মূল কারণ নম্বর দুই: DNS ইন্টারসেপশন ব্যর্থতা। Captive Portal রিডাইরেকশনটি গেটওয়ে দ্বারা HTTP প্রোব ইন্টারসেপ্ট করার উপর নির্ভর করে। কিন্তু প্রোবটির জন্য প্রথমে একটি DNS লুকআপের প্রয়োজন হয়। যদি আপনার DNS কনফিগারেশন প্রি-অথেন্টিকেটেড ক্লায়েন্টদের এক্সটার্নাল ডোমেইন নেম রিসলভ করার অনুমতি না দেয়, তবে প্রোবটি কখনোই ফায়ার হবে না। আপনার ফায়ারওয়াল পলিসি যেন স্পষ্টভাবে আনঅথেন্টিকেটেড ক্লায়েন্টদের থেকে DNS কুয়েরি করার অনুমতি দেয় তা নিশ্চিত করুন, এবং একটি টেস্ট ডিভাইসের বিরুদ্ধে প্যাকেট ক্যাপচার রান করে আপনার DNS ইন্টারসেপশন কাজ করছে কিনা তা যাচাই করুন। মূল কারণ নম্বর তিন: অসম্পূর্ণ walled garden। Walled garden - যাকে প্রি-অথেন্টিকেশন অ্যাক্সেস কন্ট্রোল লিস্টও বলা হয় - এটি নির্ধারণ করে যে আনঅথেন্টিকেটেড গেস্টরা কোন এক্সটার্নাল ডোমেইনগুলিতে পৌঁছাতে পারবে। যদি আপনার পোর্টাল স্প্ল্যাশ পেজটি এমন একটি CDN থেকে অ্যাসেট লোড করে যা walled garden-এ নেই, তবে পেজটি একটি ফাঁকা স্ক্রিন হিসেবে রেন্ডার হবে। আপনি যদি Google, Apple বা Facebook-এর মাধ্যমে সোশ্যাল লগইন অফার করেন, তবে সেই প্রোভাইডাররা ব্যবহার করে এমন প্রতিটি OAuth ডোমেইন অবশ্যই হোয়াইটলিস্ট করা থাকতে হবে। এবং এখানে একটি গুরুত্বপূর্ণ বিষয় রয়েছে: সোশ্যাল আইডেন্টিটি প্রোভাইডাররা নিয়মিতভাবে তাদের CDN IP রেঞ্জ এবং অথেন্টিকেশন ডোমেইন আপডেট করে। ছয় মাস আগে নিখুঁতভাবে কাজ করা একটি walled garden আজ নীরবে ভেঙে যেতে পারে। ত্রৈমাসিক walled garden অডিট শিডিউল করুন এবং আপনার হার্ডওয়্যার যেখানে এটি সমর্থন করে সেখানে ওয়াইল্ডকার্ড ডোমেইন স্নুপিং ব্যবহার করুন। Cisco Meraki, HPE Aruba, Ruckus এবং Juniper Mist-এ এটি নেটিভভাবে উপলব্ধ রয়েছে। মূল কারণ নম্বর চার: HSTS রিডাইরেক্ট ব্লক করছে। HTTP Strict Transport Security, বা HSTS হলো একটি ব্রাউজার সিকিউরিটি পলিসি যা শুধুমাত্র HTTPS-এর মাধ্যমে নির্দিষ্ট ডোমেইনে সংযোগ করতে বাধ্য করে। যদি কোনো গেস্টের ডিভাইস একটি HSTS-প্রিলোডেড ডোমেইনে যোগাযোগ করার চেষ্টা করে - যার মধ্যে কার্যত প্রতিটি বড় ওয়েবসাইট অন্তর্ভুক্ত রয়েছে - এবং আপনার গেটওয়ে পোর্টালে রিডাইরেক্ট করার জন্য সেই HTTPS রিকোয়েস্টটি ইন্টারসেপ্ট করার চেষ্টা করে, তবে ব্রাউজার একটি সার্টিফিকেট মিসম্যাচ সনাক্ত করে। এটি একটি নন-বাইপাসেবল সিকিউরিটি ওয়ার্নিং দেখায় এবং রিডাইরেক্ট সম্পূর্ণরূপে ব্লক করে। সঠিক সমাধান হলো কখনোই HTTPS ইন্টারসেপশনের চেষ্টা না করা। আপনার গেটওয়ের শুধুমাত্র আনএনক্রিপ্টেড HTTP ক্যানারি প্রোব রিডাইরেক্ট করা উচিত। দীর্ঘমেয়াদী স্ট্যান্ডার্ড-ভিত্তিক সমাধান হলো RFC 8910, যা DHCP Option 114 নির্ধারণ করে। এই অপশনটি আপনার DHCP সার্ভারকে সরাসরি ক্লায়েন্ট ডিভাইসে Captive Portal 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 অ্যাড্রেসের পরিবর্তে ক্রেডেন্সিয়াল ব্যবহার করে Layer 2-এ প্রমাণীকরণ করে, যার ফলে র্যান্ডমাইজেশন অপ্রাসঙ্গিক হয়ে যায়। এবার বাস্তবায়ন নিয়ে কথা বলা যাক। বাস্তবে একটি সুসংগঠিত Captive Portal ডিপ্লয়মেন্ট আসলে কেমন দেখায়? আপনার DHCP আর্কিটেকচার দিয়ে শুরু করুন। ২০০-এর বেশি সমসাময়িক ডিভাইস আশা করা যেকোনো ভেন্যুর জন্য, একটি একক slash-24 সাবনেট থেকে সরে আসুন। slash-22 বা তার চেয়ে বড় সাবনেট ব্যবহার করুন এবং আপনার ভেন্যুর অবস্থানকালের (dwell profile) সাথে সামঞ্জস্য রেখে লিজের সময় সেট করুন। একটি হোটেল লিজের সময় ৮ ঘণ্টা সেট করে। একটি স্টেডিয়াম ৩ ঘণ্টা সেট করে। একটি শপিং সেন্টার ৯০ মিনিট সেট করে। একটি কনফারেন্স সেন্টার ৩০ মিনিট সেট করে। এরপর, প্রতিটি বড় ইভেন্টের আগে আপনার walled garden যাচাই করুন। ন্যূনতম প্রয়োজনীয় এন্ট্রিগুলো হলো: আপনার পোর্টালের ফুলি কোয়ালিফাইড ডোমেন নেম (FQDN) এবং সমস্ত সংশ্লিষ্ট CDN ডোমেন, Apple, Google, Windows এবং Firefox-এর জন্য Captive Portal সনাক্তকরণ URL-গুলি এবং আপনার সমর্থিত প্রতিটি সোশ্যাল লগইন প্রদানকারীর জন্য OAuth ডোমেনগুলি। Purple-এর প্ল্যাটফর্মে, আমরা আমাদের ক্লাউড-পরিচালিত পরিষেবার অংশ হিসেবে এই walled garden এন্ট্রিগুলো স্বয়ংক্রিয়ভাবে রক্ষণাবেক্ষণ ও আপডেট করি, যা আপনার টিমের ম্যানুয়াল রক্ষণাবেক্ষণের বোঝা দূর করে। আপনার পোর্টাল সার্টিফিকেটের জন্য, একটি স্বীকৃত সার্টিফিকেট অথরিটি থেকে সর্বজনীনভাবে বিশ্বস্ত TLS সার্টিফিকেট ব্যবহার করুন। সেলফ-সাইনড সার্টিফিকেট প্রতিটি ডিভাইসে ব্রাউজার সতর্কবার্তা দেখাবে। মেয়াদ শেষ হওয়ার আগেই সার্টিফিকেট নবায়ন করুন - মেয়াদোত্তীর্ণ সার্টিফিকেট হলো হঠাৎ পুরো ভেন্যু জুড়ে পোর্টাল ব্যর্থতার অন্যতম সাধারণ কারণ। একটি ফাঁদ যা অনেক IT টিমকে বিভ্রান্ত করে: পূর্বে প্রমাণীকৃত কোনো ডিভাইস থেকে পোর্টালটি পরীক্ষা করা। আপনার ডিভাইসের সেশনটি এখনও সক্রিয় রয়েছে, তাই আপনি পোর্টালটিকে সম্পূর্ণরূপে বাইপাস করেন এবং সিদ্ধান্ত নেন যে সবকিছু ঠিকঠাক কাজ করছে। সর্বদা একটি সম্পূর্ণ নতুন, অপ্রমাণিত অবস্থার ডিভাইস থেকে পরীক্ষা করুন - হয় একটি নতুন ডিভাইস, অথবা এমন একটি ডিভাইস যেখানে আপনি নেটওয়ার্কটি 'forget' করেছেন এবং WiFi প্রোফাইলটি মুছে ফেলেছেন। আসুন আপনাকে দুটি বাস্তব পরিস্থিতি দেওয়া যাক যা এই নীতিগুলোকে স্পষ্টভাবে তুলে ধরে। পরিস্থিতি এক: সেন্ট্রাল লন্ডনের একটি ৩৫০ রুমের হোটেল। এই প্রপার্টিটি গেস্ট WiFi-এর জন্য একটিমাত্র স্ল্যাশ-২৪ সাবনেট ব্যবহার করছিল। একটি বড় কনফারেন্সের সময়, ৪০০ জন প্রতিনিধি একই সাথে সেখানে উপস্থিত হন। ২০ মিনিটের মধ্যে, DHCP পুল খালি হয়ে যায়। অতিথিরা কানেক্টেড থাকার কথা জানালেও তারা পোর্টাল বা ইন্টারনেটে পৌঁছাতে পারছিলেন না। এর তাৎক্ষণিক সমাধান ছিল সাবনেটটিকে স্ল্যাশ-২২-এ সম্প্রসারিত করা, যা ১,০২২টি ব্যবহারযোগ্য অ্যাড্রেস প্রদান করে এবং লিজ টাইম ২৪ ঘণ্টা থেকে কমিয়ে ৮ ঘণ্টা করা। দীর্ঘমেয়াদী সমাধান ছিল Purple-এর ক্লাউড-ম্যানেজড Captive Portal বাস্তবায়ন করা, যা রিয়েল টাইমে DHCP পুল ব্যবহার মনিটর করে এবং পুল খালি হওয়ার আগেই নেটওয়ার্ক টিমকে সতর্ক করে। এই পরিবর্তনের ৪৮ ঘণ্টার মধ্যে পোর্টাল ব্যর্থতার হার প্রায় শূন্যে নেমে আসে। পরিস্থিতি দুই: ২০০টি আউটলেট বিশিষ্ট একটি বড় রিটেইল চেইন। চেইনটি তাদের গেস্ট পোর্টালে Google এবং Facebook-এর মাধ্যমে সোশ্যাল লগইন ব্যবহার করত। Google তার OAuth পরিকাঠামো আপডেট করার পর, নতুন অথেন্টিকেশন ডোমেনগুলো walled garden-এ ছিল না। অতিথিরা পোর্টাল পেজে পৌঁছাতে পারলেও সোশ্যাল লগইন বাটনে ক্লিক করার পর ফাঁকা স্ক্রিন আসছিল। চেইনটির IT টিম এই সমস্যাটি চিহ্নিত করার আগে এটি নির্ণয় করতে দুই দিন সময় ব্যয় করে। একবার চিহ্নিত হওয়ার পর সমাধান করতে মাত্র ১০ মিনিট সময় লেগেছিল। শিক্ষা: ক্লাউড-ভিত্তিক OAuth প্রদানকারীদের জন্য আপনার walled garden-এ কখনই IP অ্যাড্রেস হার্ডকোড করবেন না। ওয়াইল্ডকার্ড ডোমেন এন্ট্রি ব্যবহার করুন এবং প্রতি ত্রৈমাসিকে সেগুলো পর্যালোচনা করুন। এখন ভেন্যু IT টিমগুলোর কাছ থেকে নিয়মিত শোনা কিছু দ্রুত প্রশ্নোত্তরের পালা। পোর্টালটি কেন আইফোনে কাজ করে কিন্তু Android ডিভাইসে কাজ করে না? Android তার প্রোব URL হিসেবে connectivitycheck.gstatic.com ব্যবহার করে। যদি সেই ডোমেনটি আপনার ফায়ারওয়াল দ্বারা ব্লক করা থাকে বা আপনার walled garden-এ না থাকে, তবে Android ডিভাইসগুলো কখনই পোর্টালটি ট্রিগার করে না। এটি স্পষ্টভাবে যোগ করুন। একজন অতিথি বলছেন যে পোর্টালটি লোড হয়েছে কিন্তু লগইন করার পরে তারা অনলাইনে যেতে পারছেন না। এটি প্রায় সবসময়ই একটি RADIUS অথরাইজেশন ব্যর্থতা। আপনার ওয়্যারলেস কন্ট্রোলার থেকে RADIUS সার্ভারে পৌঁছানো যাচ্ছে কিনা তা পরীক্ষা করুন, উভয় দিকে শেয়ারড সিক্রেট মিলছে কিনা তা যাচাই করুন এবং Access-Reject মেসেজের জন্য RADIUS লগগুলো পর্যালোচনা করুন। কয়েক মিনিট পর পর লগ আউট হয়ে যাওয়া অতিথিদের আমরা কীভাবে হ্যান্ডেল করব? আপনার আইডল টাইমআউট (idle timeout) সেটিং পরীক্ষা করুন। অনেক কন্ট্রোলারে ডিফল্ট হিসেবে ৫ মিনিটের আইডল টাইমআউট থাকে, যা ইন্টারঅ্যাকশনের মাঝে স্লিপ মোডে চলে যাওয়া মোবাইল ডিভাইসগুলোর জন্য অত্যন্ত কম। হসপিটালিটি এবং রিটেইল পরিবেশের জন্য আইডল টাইমআউট কমপক্ষে ৩০ মিনিট সেট করুন। আজকের ব্রিফিংয়ের মূল পয়েন্টগুলো সংক্ষেপে তুলে ধরা হলো। গেস্ট WiFi Captive Portal ব্যর্থতা ছয়টি ক্যাটাগরিতে পড়ে: DHCP পুল শেষ হয়ে যাওয়া, DNS ইন্টারসেপশন ব্যর্থতা, অসম্পূর্ণ walled garden, HSTS রিডাইরেক্ট ব্লকিং, ক্লায়েন্ট ডিভাইসে অ্যাক্টিভ VPN এবং MAC অ্যাড্রেস র্যান্ডমাইজেশন। প্রতিটিরই একটি নির্দিষ্ট, পরীক্ষাযোগ্য সমাধান রয়েছে। আপনার IT টিমের জন্য তাৎক্ষণিক পদক্ষেপগুলো হলো: আপনার DHCP লিজ টাইম এবং সাবনেট সাইজিং অডিট করা, আপনার সোশ্যাল লগইন প্রদানকারীদের বর্তমান OAuth ডোমেনগুলোর সাথে আপনার walled garden যাচাই করা এবং প্রতিটি কনফিগারেশন পরিবর্তনের পর একটি নতুন আন-অথেন্টিকেটেড ডিভাইস থেকে আপনার পোর্টাল পরীক্ষা করা। আপনার দীর্ঘমেয়াদী রোডম্যাপের জন্য, ফিরে আসা দর্শকদের জন্য captive portal re-authentication-এর উত্তরসূরি হিসেবে OpenRoaming-কে মূল্যায়ন করুন। প্রযুক্তিটি পরিপক্ক, এর মানদণ্ডগুলো IEEE 802.1X এবং WPA3-Enterprise-এর অধীনে প্রতিষ্ঠিত, এবং Purple এটিকে Connect প্ল্যানের অধীনে কোনো অতিরিক্ত সফটওয়্যার খরচ ছাড়াই উপলব্ধ করে। Purple ৮০,০০০-এরও বেশি ভেন্যুতে কাজ করে এবং শুধুমাত্র ২০২৪ সালেই ৪৪০ মিলিয়ন লগইন প্রসেস করেছে। আমরা এই ব্রিফিংয়ে বর্ণিত প্রতিটি ত্রুটির ধরণ দেখেছি - এবং সেগুলো প্রতিরোধ করার জন্য প্রয়োজনীয় টুলিং তৈরি করেছি। আপনার বিদ্যমান Cisco Meraki, HPE Aruba, Ruckus, বা Juniper Mist ইনফ্রাস্ট্রাকচারের সাথে Purple-এর ক্লাউড ওভারলে কীভাবে সংহত হতে পারে তা অন্বেষণ করতে চাইলে, purple.ai ভিজিট করুন অথবা আপনার অ্যাকাউন্ট ম্যানেজারের সাথে কথা বলুন। শোনার জন্য ধন্যবাদ।