guest WiFi কীভাবে সেট আপ করতে হয় সে সম্পর্কে সবচেয়ে সাধারণ উপদেশটি এখনও ভুল। এটি সাধারণত এইভাবে করা হয়: একটি দ্বিতীয় SSID তৈরি করুন, একটি পাসওয়ার্ড যোগ করুন, সম্ভবত একটি স্প্ল্যাশ পেজ চালু করুন এবং এটিকে নিরাপদ বলুন।
এটি একটি হোম সলিউশন, কোনো এন্টারপ্রাইজ ডিজাইন নয়।
একটি বাস্তব ভেন্যু, হোটেল, ক্লিনিক, রিটেইল সাইট, স্টুডেন্ট প্রোপার্টি বা মিশ্র-ব্যবহারের বিল্ডিংয়ে, guest WiFi ঠিক নিরাপত্তা, কমপ্লায়েন্স এবং গ্রাহক অভিজ্ঞতার সংযোগস্থলে অবস্থান করে। আপনি যদি এটিকে একটি সাধারণ ফিচার হিসেবে বিবেচনা করেন, তাহলে আপনি একটি ভঙ্গুর নেটওয়ার্ক, একটি দুর্বল সাইন-ইন প্রক্রিয়া এবং কে কখন সংযুক্ত হয়েছে এবং অ্যাক্সেস প্রত্যাহার করার প্রয়োজন হলে কী করা উচিত তার ওপর খুব কম নিয়ন্ত্রণ পাবেন।
একটি সঠিক ডিপ্লয়মেন্ট দেখতে ভিন্ন হয়। আপনার অভ্যন্তরীণ সিস্টেমগুলি থেকে কঠোর পৃথকীকরণ, আপনার পরিবেশের সাথে সামঞ্জস্যপূর্ণ একটি জয়েনিং অভিজ্ঞতা এবং এমন একটি অথেন্টিকেশন মডেল প্রয়োজন যা আপনার একই এস্টেটে ভিজিটর, ঠিকাদার, বাসিন্দা, কর্মী এবং বিভিন্ন লিগ্যাসি ডিভাইস থাকা সত্ত্বেও কাজ করে। সেখানেই প্রাথমিক গাইডগুলি সাধারণত শেষ হয় এবং প্রকৃত অপারেশনাল কাজ শুরু হয়।
কেন আপনার বেসিক guest WiFi একটি দায়বদ্ধতা
একটি শেয়ারড গেস্ট পাসওয়ার্ড নিরাপদ মনে হতে পারে কারণ এটি নিয়ন্ত্রণের উপস্থিতি তৈরি করে। বাস্তবে, এটি প্রায়শই বিপরীতটি করে। একবার সেই পাসওয়ার্ডটি রিসেপশনে প্রিন্ট করা হলে, একটি নিশ্চিতকরণ ইমেলে পাঠানো হলে, বারের পিছনে পোস্ট করা হলে বা বিভিন্ন সাইট জুড়ে পুনরায় ব্যবহার করা হলে, কে কখন যুক্ত হতে পারে তার উপর আপনি অর্থপূর্ণ নিয়ন্ত্রণ হারাবেন।
অনেক টিম যতটা মনে করে এটি তার চেয়ে বেশি গুরুত্বপূর্ণ কারণ guest WiFi আর কেবল একটি অতিরিক্ত সুবিধা নয়। ইউকে-র ব্যবহারকারীরা তাৎক্ষণিক কানেক্টিভিটি আশা করে পৌঁছান, এবং এখানে উল্লেখ করা Ofcom-এর পরিসংখ্যান দেখায় যে ইউকে-র প্রাপ্তবয়স্করা ২০২৪ সালে প্রতিদিন গড়ে ৪ ঘণ্টা ২০ মিনিট অনলাইনে কাটিয়েছেন, যেখানে স্মার্টফোনের মালিকানা ছিল ৯১% । আপনার নেটওয়ার্ক যুক্ত হওয়ার জন্য জটিল হলে, অস্থির হলে বা অনিরাপদ হলে, গেস্টরা তা দ্রুত বুঝতে পারেন।
বেসিক সেটআপগুলি যেখানে ভুল করে
বেশিরভাগ দুর্বল ডিপ্লয়মেন্ট এই তিনটি উপায়ের যেকোনো একটিতে ব্যর্থ হয়:
- তারা একটি পৃথক পাসওয়ার্ডকে পৃথকীকরণের সাথে গুলিয়ে ফেলে: একই অন্তর্নিহিত নেটওয়ার্কে একটি নতুন পাসওয়ার্ড কোনো নিরাপত্তা সীমানা নয়।
- তারা ওপেন অ্যাক্সেস এবং একটি স্প্ল্যাশ পেজের উপর নির্ভর করে: এটি ব্র্যান্ডিং বা শর্তাবলী গ্রহণের ক্ষেত্রে সাহায্য করতে পারে, তবে এটি প্রকৃত নেটওয়ার্ক সুরক্ষার বিকল্প নয়।
- তারা আইডেন্টিটি এবং লাইফসাইকেল উপেক্ষা করে: একজন ভাড়াটে চলে গেলে, একজন ঠিকাদার চলে গেলে বা কোনো ফিরে আসা গেস্ট কোনো ঝামেলা ছাড়াই পুনরায় কানেক্ট করতে চাইলে কী হবে তা কেউ জিজ্ঞাসা করে না।
একটি গেস্ট নেটওয়ার্ক একটি নিয়ন্ত্রিত বাহ্যিক জোনের মতো ডিজাইন করা উচিত, অফিসের LAN-এর কোনো অতিরিক্ত কোণের মতো নয়।
অন্য সমস্যাটি হলো হাতছাড়া হওয়া সুযোগ। একটি শেয়ারড কোডসহ বেসিক SSID আপনাকে খুব কম অন্তর্দৃষ্টি এবং প্রায় কোনো নমনীয়তা দেয় না। আপনি একজন বাসিন্দা এবং একজন কনফারেন্স অ্যাটেন্ডির মধ্যে, একজন ওয়ান-টাইম ক্যাফে ভিজিটর এবং একজন রিপিট হোটেল গেস্টের মধ্যে, অথবা একজন স্টাফের নিজস্ব ফোন এবং একজন গেস্টের ট্যাবলেটের মধ্যে সহজেই পার্থক্য করতে পারবেন না যা কেবল একদিনের জন্যই সেখানে এসেছে।
আপনি যদি কীভাবে গেস্ট WiFi সেট আপ করবেন সে বিষয়ে গুরুতর হন, তবে তবে এই ধারণাটি বর্জন করা শুরু করুন যে "গেস্ট" মানে "কম গুরুত্বপূর্ণ"। বেশিরভাগ প্রতিষ্ঠানে, এটি আপনার চালানো সবচেয়ে বেশি উন্মুক্ত নেটওয়ার্ক পরিষেবাগুলির মধ্যে একটি।
নিরাপত্তার জন্য আপনার নেটওয়ার্ক ফাউন্ডেশন তৈরি করা
গেস্ট WiFi সম্পর্কে চিন্তা করার সবচেয়ে পরিষ্কার উপায় হলো এটিকে একটি ডিজিটাল গেস্ট হাউস হিসেবে বিবেচনা করা। আপনি দর্শকদের মূল ভবনের চাবি দিয়ে এই আশা করে বসে থাকেন না যে তারা সঠিক রুমেই থাকবে। আপনি তাদের একটি পৃথক প্রবেশদ্বার, স্পষ্ট সীমানা এবং কেবল তাদের যা প্রয়োজন তাতেই অ্যাক্সেস দেন।
এই নীতিটি UK বেসলাইন নিরাপত্তা নির্দেশিকার সাথে মেলে। Cyber Essentials গেস্ট এবং স্টাফ নেটওয়ার্কের মধ্যে বিভাজন দাবি করে, যেখানে ভিজিটরদের একটি পৃথক SSID বা VLAN-এ রাখা হয় এবং ডিফল্টরূপে অভ্যন্তরীণ সিস্টেমে অ্যাক্সেস ব্লক করার জন্য ফায়ারওয়াল কনফিগার করা হয় ।
নেটওয়ার্ক সঠিকভাবে আলাদা করুন
একটি সুরক্ষিত গেস্ট ডেপ্লয়মেন্ট শুরু হয় আর্কিটেকচার দিয়ে, ব্র্যান্ডিং দিয়ে নয়। অন্ততপক্ষে, যে কেউ সংযোগ করার আগে এই কন্ট্রোলগুলি তৈরি করুন:
- ডেডিকেটেড SSID: একটি গেস্ট SSID তৈরি করুন যা স্টাফ এবং অপারেশনাল ওয়্যারলেস নেটওয়ার্ক থেকে আলাদা।
- VLAN সেগমেন্টেশন: সেই SSID টিকে নিজস্ব VLAN-এ ম্যাপ করুন যাতে গেস্ট ট্রাফিক আপনার প্রোডাকশন নেটওয়ার্কের বাইরে থাকে।
- ফায়ারওয়াল পলিসি: ডিফল্টরূপে গেস্ট সেগমেন্ট থেকে ইন্টারনাল সাবনেটে অ্যাক্সেস অস্বীকার করুন, তারপর শুধুমাত্র যা প্রয়োজন তা অনুমোদন করুন।
- আলাদা অ্যাড্রেসিং এবং পরিষেবা: একটি ডেডিকেটেড DHCP স্কোপ ব্যবহার করুন এবং ইন্টারনাল DNS, প্রিন্টার, ফাইল শেয়ার বা ম্যানেজমেন্ট ইন্টারফেসে অ্যাক্সেস লিক হওয়া এড়ান।
যদি আপনার কন্ট্রোলার রোল-ভিত্তিক পলিসি সমর্থন করে, তবে সেগুলি ব্যবহার করুন। যদি এটি ডায়নামিক VLAN অ্যাসাইনমেন্ট সমর্থন করে, তবে এখনই এটির পরিকল্পনা করুন এমনকি আপনি প্রথম দিন এটি ব্যবহার না করলেও। ভালো গেস্ট WiFi সাধারণত সময়ের সাথে সাথে প্রসারিত হয়। খারাপ গেস্ট WiFi চাপের মুখে পুনর্নির্মাণ করতে হয়।
যেসব কন্ট্রোল আপোষহীন হওয়া উচিত
মার্কেটিং ভাষা বাদ দিলে টেকনিক্যাল বেসলাইনটি বেশ সহজ সরল:
- গেস্ট SSID তৈরি করুন।
- WPA2 বা WPA3 প্রয়োগ করুন।
- ক্লায়েন্ট আইসোলেশন বা গেস্ট আইসোলেশন সক্ষম করুন।
- প্রাথমিক LAN-এ অ্যাক্সেস ব্লক করুন।
- একটি বাস্তব ক্লায়েন্ট ডিভাইস থেকে পরীক্ষা করুন।
এই সিকোয়েন্সটি সহজ শোনায় কারণ এটি আসলেই সহজ। শৃঙ্খলা আসে তখন যখন কেউ দ্রুত লঞ্চ করার অনুরোধ করলেও কোনো ধাপ বাদ না দিয়ে কাজ করা হয়।
ব্যবহারিক নিয়ম: যদি কোনো গেস্ট ডিভাইস আপনার প্রিন্টারগুলো খুঁজে পায়, মিটিং রুমের স্ক্রিনে কাস্ট করতে পারে, বা কোনো অ্যাডমিন পেজে অ্যাক্সেস পায়, তবে নেটওয়ার্কের কাজ এখনও শেষ হয়নি।
প্রোডাকশন সেটিংস পরিবর্তন করার আগে একটি প্রি-ডিপ্লয়মেন্ট চেকলিস্ট ব্যবহার করলে অনেক টিম উপকৃত হয়। আপনার ডিজাইনে একটি এন্টারপ্রাইজ পরিবেশের জন্য প্রয়োজনীয় কন্ট্রোল এবং অনবোর্ডিং অপশনগুলো অন্তর্ভুক্ত আছে কিনা তা যাচাই করার জন্য এই গেস্ট WiFi ফিচার চেকলিস্ট একটি দরকারী উপায়।
অ্যাডমিনিস্ট্রেটররা যেখানে ভুল করেন
আমি সাধারণত যে ব্যর্থতাগুলো দেখি সেগুলো বেশ সাধারণ, কোনো জটিল বিষয় নয়। একটি গেস্ট SSID স্টাফ ডিভাইসের মতো একই ব্রডকাস্ট ডোমেনে তৈরি করা হয়। AirPlay-এর সমস্যা সমাধানের জন্য কেউ একজন আইসোলেশন বন্ধ করে রেখে দেয়। একটি স্প্ল্যাশ পোর্টাল সক্রিয় করা হয়, কিন্তু নিচের WLAN এখনও ওপেন থাকে। অথবা পরীক্ষার জন্য যুক্ত করা একটি ফায়ারওয়াল নিয়ম আর কখনই সরানো হয় না।
সেটআপের পর এই সংক্ষিপ্ত ভ্যালিডেশন পাসটি ব্যবহার করুন:
- গেস্ট হিসেবে যুক্ত হন: ইন্টারনেট অ্যাক্সেস কাজ করছে কিনা তা নিশ্চিত করুন।
- স্থানীয় রিসোর্সগুলো পরীক্ষা করুন: প্রিন্টার, ফাইল শেয়ার এবং অভ্যন্তরীণ ওয়েব অ্যাপগুলো যাতে অ্যাক্সেস করা না যায় তা নিশ্চিত করুন।
- ইস্ট-ওয়েস্ট ভিজিবিলিটি পরীক্ষা করুন: একটি গেস্ট ডিভাইস যাতে অন্য একটি গেস্ট ডিভাইসকে দেখতে না পায় তা যাচাই করুন।
- ফেইল-ওপেন আচরণ পর্যালোচনা করুন: পোর্টাল বা অথেন্টিকেশন সার্ভিস অনুপলব্ধ থাকলে গেস্টদের ব্লক করা হবে নাকি সীমিত পলিসির মাধ্যমে অনুমতি দেওয়া হবে তা নির্ধারণ করুন।
এটিই হলো ভিত্তি। পোর্টাল, অ্যানালিটিক্স, আইডেন্টিটি, Passpoint সহ বাকি সবকিছু কেবল তখনই কাজ করে যখন এই লেয়ারটি মজবুত থাকে।
আপনার গেস্ট অনবোর্ডিং অভিজ্ঞতা নির্বাচন করা
নেটওয়ার্কটি সঠিকভাবে আইসোলেট করার পর, পরবর্তী সিদ্ধান্ত হলো মানুষ কীভাবে এটিতে যুক্ত হবে। এই সিদ্ধান্ত নেওয়ার সময় অনেক প্রজেক্ট আবার সাধারণ গ্রাহক-ভিত্তিক চিন্তাভাবনায় ফিরে যায়। টিমগুলো ভেন্যুর জন্য সঠিক পদ্ধতি বেছে না নিয়ে IT-এর জন্য সবচেয়ে সহজ সাইন-ইন পদ্ধতিটি বেছে নেয়।
এই আপসের ফলাফল দ্রুতই সামনে আসে। এখানে সংক্ষেপিত নির্দেশিকায় উল্লেখ করা হয়েছে যে শেয়ারড পাসওয়ার্ড এবং বেসিক পোর্টালগুলো ক্রমেই অপ্রচলিত হয়ে পড়ছে, এবং এটি ইউকে সরকারের Cyber Security Breaches Survey 2025-এর তথ্যও উল্লেখ করে যেখানে দেখা গেছে যে ৪৩% ব্যবসা পূর্ববর্তী ১২ মাসে সাইবার লঙ্ঘন বা আক্রমণের সম্মুখীন হয়েছে । অন্য কথায়, অ্যাক্সেস ডিজাইন অত্যন্ত গুরুত্বপূর্ণ।
প্রতিটি পদ্ধতির প্রকৃত শক্তি এবং দুর্বলতা
একটি Captive Portal এখনও দরকারী, তবে আপনাকে এটি কী তা স্পষ্ট বুঝতে হবে। এটি একটি অনবোর্ডিং এবং পলিসি টুল। এটি আপনার প্রাথমিক সিকিউরিটি কন্ট্রোল নয়।
একটি পোর্টাল কী করতে পারে এবং কী করতে পারে না সে বিষয়ে মার্কেটিং, অপারেশন এবং নেটওয়ার্কিং টিমকে একমত করতে হলে Captive Portal সম্পর্কে Purple-এর ব্যাখ্যা একটি ভালো রেফারেন্স পয়েন্ট।
এখানে ব্যবহারিক তুলনা দেওয়া হলো:
| পদ্ধতি | নিরাপত্তার স্তর | ব্যবহারকারীর অভিজ্ঞতা | ডেটা ক্যাপচার | যাদের জন্য সবচেয়ে উপযোগী |
|---|---|---|---|---|
| শেয়ার করা পাসওয়ার্ড | কম থেকে মাঝারি, পরিবর্তন এবং সেগমেন্টেশনের ওপর নির্ভরশীল | পরিচিত, কিন্তু পাসওয়ার্ড পরিবর্তন হলে বা ব্যাপকভাবে শেয়ার করা হলে জটিল | খুবই সামান্য | সীমিত প্রয়োজনীয়তা সম্পন্ন ছোট সাইট |
| Captive Portal সহ ওপেন নেটওয়ার্ক | একা ব্যবহার করা হলে কম | প্রথমবার যুক্ত হওয়া সহজ, তবে ডিভাইসভেদে অসামঞ্জস্যপূর্ণ | ফর্ম-ভিত্তিক হলে ভালো | স্বল্পকালীন থাকার পাবলিক ভেন্যু |
| ভাউচার বা সময়-সীমিত কোড | মাঝারি | ব্যবস্থাপনাযোগ্য, তবে ডেস্ক বা স্টাফের ওপর নির্ভরতা বাড়ায় | মাঝারি | হোটেল, ইভেন্ট, পরিচালিত অ্যাক্সেস উইন্ডো |
| ইমেল বা SMS রেজিস্ট্রেশন | মাঝারি | ফর্মটি ছোট হলে গ্রহণযোগ্য | শক্তিশালী ফার্স্ট-পার্টি ডেটা সংগ্রহের সম্ভাবনা | রিটেইল, হসপিটালিটি, ভেন্যু |
| স্পন্সরড অ্যাক্সেস | আরও শক্তিশালী নিয়ন্ত্রণ | ধীরগতির, তবে নিয়ন্ত্রিত পরিবেশের জন্য দরকারী | মাঝারি থেকে শক্তিশালী | কর্পোরেট ভিজিটর, স্বাস্থ্যসেবা, সংরক্ষিত সাইট |
| ব্যবহারকারী প্রতি অথেন্টিকেশন | উচ্চ | কনফিগার করার পর দীর্ঘমেয়াদে আরও ভালো অভিজ্ঞতা | শক্তিশালী | মাল্টি-ইউজার, কমপ্লায়েন্স-সংবেদনশীল পরিবেশ |
| Passpoint বা OpenRoaming স্টাইলের অনবোর্ডিং | নিরবচ্ছিন্ন এনক্রিপ্টেড অ্যাক্সেস সহ উচ্চ | পুনরাবৃত্তি ভিজিট এবং রোমিংয়ের জন্য সেরা | বাস্তবায়নের ওপর নির্ভর করে | হসপিটালিটি, পরিবহন, বড় ভেন্যু, মাল্টি-সাইট এস্টেট |
বাস্তবে যা কাজ করে
একটি ক্যাফে বা এককালীন ইভেন্টের জন্য, একটি সাধারণ Captive Portal যথেষ্ট হতে পারে যদি মূল WLAN এনক্রিপ্টেড এবং আইসোলেটেড থাকে। একটি হোটেল গ্রুপ, ক্লিনিক, শপিং সেন্টার, বা পরিবহন পরিবেশের জন্য, একটি স্ট্যাটিক পাসওয়ার্ড সাধারণত সহায়তার বোঝা এবং নিরাপত্তার জন্য হুমকি হয়ে দাঁড়ায়।
যখন আপনার একটি ব্র্যান্ডেড অভিজ্ঞতা এবং আইনসম্মত ফার্স্ট-পার্টি ডেটা সংগ্রহের প্রয়োজন হয়, তখন ইমেল রেজিস্ট্রেশন একটি ভালো মধ্যপন্থা হতে পারে। SMS কাজ করতে পারে, তবে এটি ডেলিভারি সংক্রান্ত বিষয়ে আরও বেশি জটিলতা এবং সহায়তার সমস্যা তৈরি করে। সোশ্যাল লগইন একসময় সাধারণ ছিল। এটি এখন কম আকর্ষণীয় যদি না এটি কোনো নির্দিষ্ট ক্যাম্পেইনের উদ্দেশ্য পূরণ করে।
কিছু পরিবেশ কোনো ধরনের লগইন জটিলতাই চায় না। সেইসব ক্ষেত্রে, টিমগুলো সাধারণত সম্পূর্ণ অথেন্টিকেশন প্রক্রিয়া ছাড়াই মিডিয়া অ্যাক্সেস বা এনগেজমেন্ট দেওয়ার উপায় খোঁজে। উদাহরণস্বরূপ, আপনি যদি কোনো ভেন্যু অ্যাক্টিভেশন চালান এবং সাধারণ কন্টেন্ট পার্টিসিপেশন চান, তবে লগইন ছাড়াই ইভেন্ট ফটো শেয়ারিংয়ের এই গাইডটি একটি দরকারী বৈপরীত্য দেখায় কারণ এটি স্পষ্ট করে যে কোথায় লগইন জটিলতা দূর করা সাহায্য করে, এবং কোথায় এটি সঠিক নেটওয়ার্ক অ্যাক্সেস নিয়ন্ত্রণের প্রয়োজনীয়তাকে প্রতিস্থাপন করে না।
সবচেয়ে ভালো অনবোর্ডিং ফ্লো হলো সেটি যা ব্যবহারকারীর জার্নির সাথে মেলে এবং প্রতি সপ্তাহে পলিসি নতুন করে না লিখেও IT-কে অ্যাক্সেস প্রত্যাহার, সেগমেন্ট এবং অডিট করার সুবিধা দেয়।
কখন পোর্টাল এবং পাসওয়ার্ডের বাইরে চিন্তা করবেন
অতিথিরা যদি নিয়মিত ফিরে আসেন, কর্মীরা সাইটগুলোর মধ্যে স্থানান্তরিত হন, অথবা কোনো প্রপার্টিতে স্থায়ী বাসিন্দা ও অস্থায়ী ব্যবহারকারী উভয়ই থাকেন, তবে কেবল আরও ভালো স্প্ল্যাশ পেজের পরিবর্তে identity-based onboarding এবং Passpoint/OpenRoaming নিয়ে কাজ করা শুরু করুন।
এই পরিবর্তন একসাথেই বেশ কয়েকটি দীর্ঘস্থায়ী সমস্যার সমাধান করে:
- পাসওয়ার্ড শেয়ারিং বন্ধ হয়: অ্যাক্সেস ব্যক্তি বা ডিভাইসের সাথে যুক্ত করা যেতে পারে।
- পুনরাবৃত্তি ভিজিট আরও সহজ হয়: ফিরে আসা ব্যবহারকারীরা প্রতিবার বিশদ বিবরণ পুনরায় না দিয়েই আবার সংযুক্ত হতে পারেন।
- অ্যাক্সেস প্রত্যাহার সহজ হয়: সাইট-ওয়াইড কোড পরিবর্তন না করে কেবল আইডেন্টিটি বা পলিসিটি সরিয়ে দিন।
- প্রথম প্যাকেট থেকেই এনক্রিপশন শুরু হয়: এটি ওপেন SSID এবং ওয়েব ফর্মের চেয়ে অনেক ভালো একটি সমাধান।
আপনি যদি একটি বড় প্রপার্টির জন্য কীভাবে গেস্ট WiFi সেট আপ করবেন তা ভাবছেন, তবে সাধারণত এটিই হলো মূল টার্নিং পয়েন্ট। তখন আপনি "মানুষ কীভাবে আমাদের স্প্ল্যাশ পেজ দেখবে?" তা চিন্তা করা বন্ধ করে প্রশ্ন করা শুরু করেন, "কীভাবে আমরা তাদের বড় স্কেলে নির্ভুলভাবে, নিরাপদে এবং বারবার অথেন্টিকেট করব?"
অথেন্টিকেশন ইন্টিগ্রেশন এবং ডিভাইস পরিচালনা
অধিকাংশ গেস্ট WiFi বিষয়ক পরামর্শের সবচেয়ে বড় ফাঁকটি SSID বা স্প্ল্যাশ পেজে নয়। এটি হলো আইডেন্টিটিতে। সাধারণ নির্দেশিকাগুলোতে খুব কমই আলোচনা করা হয় যে, যখন একই প্রপার্টিতে স্বল্পমেয়াদী ভিজিটর, স্থায়ী বাসিন্দা, ঠিকাদার, স্টাফ এবং আনম্যানেজড ডিভাইস থাকে এবং সকলের জন্য আলাদা অ্যাক্সেস নিয়মের প্রয়োজন হয়, তখন কী করতে হবে।
যুক্তরাজ্যে এটি অত্যন্ত গুরুত্বপূর্ণ কারণ এখানে উল্লিখিত ইংলিশ হাউজিং সার্ভে অনুযায়ী বেসরকারি ভাড়া খাতের প্রায় ৪.৭ মিলিয়ন পরিবার এবং সামাজিক ভাড়া খাতের প্রায় ০.৬ মিলিয়ন পরিবার সহ মাল্টি-টেন্যান্ট এবং প্রপার্টি-স্কেল অ্যাক্সেস কন্ট্রোলের মতো বিশাল ক্ষেত্রগুলোকে মূলধারার নির্দেশিকাগুলো প্রায়শই এড়িয়ে যায় ।
কন্ট্রোল প্লেন হিসেবে আইডেন্টিটি ব্যবহার করুন
একটি আধুনিক ডেপ্লয়মেন্টের সাথে সাথেই দুটি প্রশ্নের উত্তর পাওয়া উচিত:
- কে বা কী কানেক্ট করছে?
- সেই আইডেন্টিটিকে কী কী অ্যাক্সেস করার অনুমতি দেওয়া উচিত?
ঠিক এখানেই RADIUS এবং ডিরেক্টরি ইন্টিগ্রেশনের গুরুত্ব চলে আসে। আপনি যদি আগে এটি নিয়ে কাজ না করে থাকেন, তবে একটি RADIUS সার্ভার কী কাজ করে তার এই ওভারভিউটি একটি দরকারী ভূমিকা হতে পারে। ব্যবহারিক অর্থে, এটি আপনার ওয়্যারলেস নেটওয়ার্ক এবং আপনার আইডেন্টিটি সোর্সের মধ্যে সিদ্ধান্তের মূল মাধ্যম হয়ে ওঠে।
কর্মী অ্যাক্সেসের জন্য, WiFi প্রমাণীকরণকে আপনার ডিরেক্টরি প্ল্যাটফর্ম যেমন Entra ID, Google Workspace, বা Okta-এর সাথে সংযুক্ত করুন। এটি আপনাকে আলাদা ওয়্যারলেস পাসওয়ার্ড লাইফসাইকেল বজায় না রেখেই জয়েনার, মুভার, লিভার নিয়ন্ত্রণ প্রদান করে। যদি একজন ব্যবহারকারী সংস্থা ছেড়ে চলে যান, তবে তার নেটওয়ার্ক অ্যাক্সেস আইডেন্টিটি পরিবর্তনের সাথে সাথেই বন্ধ হয়ে যায়।
রিয়েল এস্টেটে কাজ করে এমন প্যাটার্ন
বিভিন্ন পরিবেশের জন্য আলাদা মডেলের প্রয়োজন হয়।
হসপিটালিটি এবং ভেন্যু
পাবলিক ব্যবহারকারীদের জন্য শর্ট-সেশন গেস্ট অ্যাক্সেস ব্যবহার করুন, তবে সম্ভব হলে স্ট্যাটিক সাইট-ওয়াইড পাসওয়ার্ড এড়িয়ে চলুন। কনফারেন্স স্পেস বা ভিআইপি নেটওয়ার্কের জন্য, স্পষ্ট মেয়াদ শেষ হওয়ার তারিখ সহ পলিসি-ভিত্তিক অ্যাক্সেস প্রদান করুন। যদি আপনার প্ল্যাটফর্ম Passpoint সমর্থন করে, তবে বারবার আসা দর্শনার্থীদের জন্য এটি পরীক্ষা করে দেখা মূল্যবান যারা দ্রুত পুনরায় সংযোগ করতে চান।
আবাসিক এবং ছাত্রাবাস
বাসিন্দাদের ঘরের মতো অভিজ্ঞতার প্রয়োজন হয়, কিন্তু অপারেটরদের এন্টারপ্রাইজ আইসোলেশন প্রয়োজন। সবাইকে একই কী দেওয়া হলে শেয়ার্ড-প্রপার্টি নেটওয়ার্কগুলো দ্রুত ভেঙে পড়ে। যেখানে সম্ভব সেখানে পৃথক বা ইউনিট-ভিত্তিক শংসাপত্র (credentials) ব্যবহার করুন, এবং আবাসন পরিবর্তন হলে অবিলম্বে অফবোর্ডিং নিশ্চিত করুন।
কর্মী এবং ঠিকাদার
এই ব্যবহারকারীদের বেনামী অতিথিদের মতো একই ওয়ার্কফ্লোতে রাখবেন না। কর্মীদের ডিরেক্টরি-ব্যাকড শংসাপত্রের সাথে প্রমাণীকরণ করা উচিত। ঠিকাদারদের প্রায়শই রিসেপশনের পাসওয়ার্ডের পরিবর্তে একটি নির্দিষ্ট আইডেন্টিটির সাথে যুক্ত স্পনসরড বা সময়-সীমাবদ্ধ অ্যাক্সেসের প্রয়োজন হয়।
মাল্টি-টেন্যান্ট WiFi ব্যর্থ হয় যখন অপারেটররা একটি পলিসি সমস্যার সমাধান একটি পাসওয়ার্ড সমস্যা দিয়ে করতে চায়।
লেগেসি এবং IoT ডিভাইসের জন্য একটি আলাদা সমাধান প্রয়োজন
অনেক চমৎকার ডিজাইনও সমস্যার সম্মুখীন হয়। স্মার্ট টিভি, প্রিন্টার, গেম কনসোল, স্ক্যানার এবং বিভিন্ন এমবেডেড ডিভাইস প্রায়শই আধুনিক ব্রাউজার-ভিত্তিক অনবোর্ডিং বা এন্টারপ্রাইজ প্রমাণীকরণ পরিচালনা করতে পারে না।
সেই ডিভাইসগুলির জন্য, আপনার প্ল্যাটফর্ম সমর্থন করলে iPSK বা অন্য কোনো প্রতি-ডিভাইস শংসাপত্র মডেল ব্যবহার করুন। এটি প্রতিটি ডিভাইসকে নিজস্ব কী এবং পলিসি দেয়, যা প্রতিটি জটিল ডিভাইসকে কখনই পরিবর্তন না হওয়া একটি শেয়ার্ড “IoT” পাসওয়ার্ডে রাখার চেয়ে অনেক বড় উন্নতি।
একটি ব্যবহারিক মডেল এইরকম দেখায়:
- কর্মীদের ল্যাপটপ এবং ফোন: ডিরেক্টরি-ভিত্তিক প্রমাণীকরণ
- অতিথিরা: ভেন্যুর উপর নির্ভর করে পোর্টাল, পাসওয়ার্ডহীন অনবোর্ডিং, বা Passpoint
- লেগেসি ডিভাইস: সীমাবদ্ধ পলিসি সহ প্রতি-ডিভাইস শংসাপত্র
- অপারেশনাল ডিভাইস: সম্পূর্ণ আলাদা SSID এবং পলিসি
মিশ্র চাহিদার পরিবেশে, Cisco আইডেন্টিটি স্ট্যাক, Aruba ClearPass, ক্লাউড-ম্যানেজড RADIUS পরিষেবা এবং ভেন্ডর-ইন্টিগ্রেটেড অনবোর্ডিং টুলের মতো প্ল্যাটফর্মগুলি গুরুত্বপূর্ণ ভূমিকা পালন করতে পারে। শেয়ার্ড পাসওয়ার্ড বা লোকাল RADIUS পরিকাঠামোর উপর নির্ভর না করে যারা পাসওয়ার্ডহীন গেস্ট অ্যাক্সেস, ডিরেক্টরি ইন্টিগ্রেশন এবং মাল্টি-টেন্যান্ট কন্ট্রোল চান, তাদের জন্য Purple-ও এই ক্যাটাগরিতে উপযুক্ত।
এটিই হলো একটি WLAN লেবেল হিসেবে “গেস্ট WiFi” এবং একটি অ্যাক্সেস স্ট্র্যাটেজি হিসেবে গেস্ট WiFi-এর মধ্যে পার্থক্য।
জনপ্রিয় ভেন্ডরদের জন্য ব্যবহারিক ডেপ্লয়মেন্ট টিপস
বেশিরভাগ ডিজাইনের ভুল হোয়াইটবোর্ড পর্যায়ে হয় না। সেগুলি ড্যাশবোর্ডে ঘটে, সাধারণত যখন কেউ খুব দ্রুত একটি উইজার্ড ক্লিক করে চলে যান।
Cisco Meraki
Meraki-তে, বিল্ট-ইন গেস্ট অপশনগুলো ব্যবহার করে সেখানেই থেমে যাওয়ার একটি প্রবণতা থাকে। এটি একটি ছোট সাইটের জন্য ঠিক আছে, তবে বড় এস্টেটের জন্য Layer 3 firewall rules, group policies, এবং traffic shaping-এর দিকে গভীর মনোযোগ দিন। প্রথম দিনে গেস্ট ইন্টারনেট অ্যাক্সেস কাজ করতে পারে, কিন্তু আপনি যদি নীতি সঠিকভাবে সংজ্ঞায়িত না করেন, তবে পরবর্তীতে যখন ভিজিটর, VIP বা ইভেন্ট ট্রাফিকের জন্য আলাদা অ্যাক্সেস লেভেলের প্রয়োজন হবে, তখন আপনাকে সমস্যায় পড়তে হবে।
Meraki-র একটি সাধারণ সমস্যা হলো অসম্পূর্ণ আইসোলেশন থাকা সত্ত্বেও পোর্টাল সফলভাবে কাজ করা। স্প্ল্যাশ পেজ লোড হয়, ব্যবহারকারীরা ওয়েব ব্রাউজ করেন, সবাই ধরে নেন কাজ শেষ। তারপর কেউ একজন আবিষ্কার করেন যে গেস্ট ক্লায়েন্টরা এখনও স্থানীয় পরিষেবাগুলিতে পৌঁছাতে পারছে কারণ ব্লকিং নিয়মগুলি সম্পূর্ণরূপে যাচাই করা হয়নি।
Aruba
Aruba-র ক্ষেত্রে, বিশেষ করে কন্ট্রোলার-ভিত্তিক এস্টেটে, এর শক্তি হলো পলিসির গভীরতা। আপনি যদি ClearPass ব্যবহার করেন, তবে ডেপ্লয়মেন্টের আগে রোলগুলি ম্যাপ করার জন্য সময় নিন। কোন বৈশিষ্ট্যগুলি একজন ব্যবহারকারীকে গেস্ট রোল, স্টাফ রোল, ঠিকাদার রোল বা একটি সীমাবদ্ধ ডিভাইস রোলে রাখবে তা নির্ধারণ করুন।
এখানকার ভুলটি হলো প্রথমবারেই অতিরিক্ত জটিল পরিকাঠামো তৈরি করা। টিমগুলি কখনও কখনও খুব বেশি নেস্টেড নীতি এবং ব্যতিক্রম তৈরি করে ফেলে, যার ফলে পরবর্তীতে কেউই আর সিস্টেমটি স্পর্শ করতে চায় না। আপনার প্রথম রিলিজটি সহজ ও পরিষ্কার রাখুন। একটি গোলকধাঁধার মতো লজিক তৈরি করার চেয়ে কয়েকটি সুনির্দিষ্ট এনফোর্সমেন্ট প্রোফাইল রাখা অনেক ভালো।
Ruckus
Ruckus-এ, গেস্ট অ্যাক্সেস অত্যন্ত নির্ভরযোগ্য হতে পারে, বিশেষ করে আতিথেয়তা-প্রধান পরিবেশে। আপনি যদি বাহ্যিক প্রমাণীকরণ সংহত করেন, তবে WLAN সেটিংস, ব্যবহারকারীর ভূমিকা নির্ধারণ এবং সঠিক Captive Portal হ্যান্ডঅফের দিকে মনোযোগ দিন।
মাঠ পর্যায়ের যে সমস্যাটির দিকে নজর দিতে হবে তা হলো পোর্টাল রিডাইরেকশনের সময় বিভিন্ন ধরণের ডিভাইসে অসঙ্গতিপূর্ণ আচরণ। রোলআউটের আগে বর্তমান iPhone, Android, Windows, এবং macOS ডিভাইসগুলির সাথে পরীক্ষা করুন। গেস্ট WiFi-র সমস্যাগুলি প্রায়শই শেষ ব্যবহারকারীদের কাছে "ইন্টারনেট ডাউন" বলে মনে হয়, যেখানে আসল সমস্যাটি কেবল পোর্টাল সনাক্তকরণে ব্যর্থতা।
Juniper Mist
Mist-এর ক্ষেত্রে সুবিধা হলো এর ভিজিবিলিটি বা দৃশ্যমানতা। ক্লাউড ড্যাশবোর্ড ক্লায়েন্টের আচরণ, অনবোর্ডিং ব্যর্থতা এবং রোমিং ইভেন্টগুলি দেখা সহজ করে তোলে। সেই দৃশ্যমানতা ব্যবহার করুন। কেবল SSID ডেপ্লয় করেই ডিফল্ট অ্যানালিটিক্স ভিউয়ের ওপর ভরসা করবেন না।
Mist পরিবেশও সুশৃঙ্খল SSID ডিজাইনকে পুরস্কৃত করে। প্রতিটি ব্যবহারকারীর ধরণের জন্য আলাদা SSID তৈরি করার কারণে আপনি যদি খুব বেশি ব্রডকাস্ট নেটওয়ার্ক তৈরি করেন, তবে আপনি দ্রুত ক্রিয়াকলাপগুলিকে জটিল করে তুলবেন। প্রতিটি পরিস্থিতির জন্য একটি করে SSID ব্যবহার না করে, যেখানে সম্ভব নীতি এবং পরিচয় ব্যবহার করুন।
UniFi
UniFi-এ, গেস্ট WiFi বেশ সহজসাধ্য, যা এর আকর্ষণ এবং ফাঁদ উভয়ই। দ্রুত একটি গেস্ট নেটওয়ার্ক তৈরি করা সহজ, তবে আপনাকে এখনও গেস্ট কন্ট্রোল, নেটওয়ার্ক আইসোলেশন এবং যেকোনো এক্সটার্নাল পোর্টাল ইন্টিগ্রেশন সাবধানে যাচাই করতে হবে।
এখানে সাধারণ ব্যর্থতা হলো কেবল বাহ্যিক সাফল্য। পোর্টালটি দেখতে চমৎকার লাগে, ভাউচার প্রিন্ট হয়, ক্লায়েন্টরা কানেক্ট করে, কিন্তু মূল সেগমেন্টেশনটি অ্যাডমিনের ধারণার চেয়েও দুর্বল থাকে। UniFi কাজটি ভালোভাবে করতে পারে, তবে এটি সেই অ্যাডমিনিস্ট্রেটরদের সুবিধা দেয় যারা ইন্টারফেসের লেবেলের ওপর ভরসা না করে অ্যাক্সেস পাথ পরীক্ষা করে দেখেন।
একটি অভ্যাস যা প্রতিটি প্ল্যাটফর্মে সময় বাঁচায়
লঞ্চ করার আগে তিনটি ডিভাইস দিয়ে বিল্ড এবং টেস্ট করুন:
- প্রথমবার কানেক্ট করার অভিজ্ঞতার জন্য একটি সাধারণ স্মার্টফোন
- পোর্টাল এবং ব্রাউজারের আচরণ দেখার জন্য একটি ল্যাপটপ
- আপনার সাইট যদি সাপোর্ট করে তবে একটি স্মার্ট টিভি বা পুরোনো ক্লায়েন্টের মতো একটি কঠিন ডিভাইস
এই সাধারণ পরীক্ষাটি আপনার গেস্টরা দেখার আগেই বেশিরভাগ প্রোডাকশন সংক্রান্ত সমস্যাগুলো ধরে ফেলে।
মনিটরিং, কমপ্লায়েন্স এবং ট্রাবলশুটিং
SSID লাইভ হয়ে গেলেই গেস্ট WiFi-এর কাজ শেষ হয়ে যায় না। এটি একটি অপারেশনাল সার্ভিস হয়ে ওঠে। যে টিমগুলো এটি ভালোভাবে পরিচালনা করে তারা ব্যবহারের বিবরণ পর্যালোচনা করে, পলিসি ড্রিপ্ট পরীক্ষা করে, অথেন্টিকেশন ব্যর্থতা পর্যবেক্ষণ করে এবং লঞ্চ করার পরে গেস্ট জার্নি পুনরায় মূল্যায়ন করে।
প্রতি সপ্তাহে কী মনিটর করবেন
অপারেশনাল কাজে সাহায্য করে এমন সংকেতগুলো দিয়ে শুরু করুন:
- অথেন্টিকেশন সাফল্য এবং ব্যর্থতার ট্রেন্ড: ব্যবহারকারীরা যদি SSID দেখতে পান কিন্তু অনবোর্ডিং সম্পন্ন করতে না পারেন, তবে সমস্যাটি সাধারণত পোর্টাল ফ্লো, পলিসি বা আপস্ট্রিম ডিপেন্ডেন্সির কারণে হয়।
- একযোগে ব্যবহারকারীর আচরণ: এমন সময় এবং স্থানগুলো খুঁজুন যেখানে ব্যবহারের অভিজ্ঞতা খারাপ হচ্ছে।
- ডিভাইসের মিশ্রণ: এটি আপনাকে জানায় যে অনবোর্ডিং প্রক্রিয়াটি মানুষ আসলে যে ধরণের ডিভাইস নিয়ে আসছে সেগুলোর জন্য উপযুক্ত কিনা।
- সেশন ড্রপের ধরণ: বারবার সংক্ষিপ্ত রিকানেক্ট হওয়া সাধারণত পোর্টাল লুপ, DHCP জটিলতা বা রোমিং সমস্যার ইঙ্গিত দেয়।
- পলিসি ব্যতিক্রম: সাময়িক অ্যাক্সেস নিয়মগুলোর স্থায়ী হয়ে যাওয়ার একটি প্রবণতা থাকে।
কোনো মনিটরিং ছাড়া একটি গেস্ট নেটওয়ার্ক সাধারণত সাপোর্ট লাইনের ভিড় বাড়িয়ে দেয়। একটি মনিটর করা নেটওয়ার্ক অপ্টিমাইজ করা সহজ হয় কারণ অভিযোগ আসার আগেই সমস্যাগুলো সামনে চলে আসে।
কমপ্লায়েন্স এবং প্রাইভেসি বজায় রাখতে অপারেশনাল নিয়মানুবর্তিতা প্রয়োজন
যুক্তরাজ্যের সংস্থাগুলির জন্য, গেস্ট WiFi প্রায়শই রেজিস্ট্রেশন ফর্ম, অ্যানালিটিক্স, CRM কানেকশন বা মার্কেটিং ওয়ার্কফ্লোর মাধ্যমে ব্যক্তিগত ডেটা স্পর্শ করে। এর অর্থ হলো প্রাইভেসি সংক্রান্ত সিদ্ধান্তগুলো পরবর্তীতে যোগ করা যায় না।
মৌলিক বিষয়গুলো কঠোরভাবে মেনে চলুন:
- কেবল আপনার যা প্রয়োজন তা সংগ্রহ করুন।
- ব্যবহারকারীদের জানান আপনি কী সংগ্রহ করছেন এবং কেন।
- মার্কেটিং সম্মতি থেকে অ্যাক্সেস কন্ট্রোল আলাদা করুন।
- লঞ্চ করার আগে ডেটা রিটেনশন পিরিয়ড বা সংরক্ষণের সময়সীমা নির্ধারণ করুন।
- অ্যাক্সেস রিকোয়েস্ট, ডিলিট করার রিকোয়েস্ট এবং পলিসি সংক্রান্ত প্রশ্নের প্রসেস যাতে অপারেশন টিম জানে তা নিশ্চিত করুন।
নেটওয়ার্কিং টিমের আইনি বিভাগ হওয়ার প্রয়োজন নেই। তবে তাদের এমন কোনো জয়েন ফ্লো তৈরি করা এড়াতে হবে যা এমন ডেটা সংগ্রহ করে যা কেউ যুক্তিযুক্ত বা পরিচালনা করতে পারে না।
আপনার গেস্ট পোর্টাল যদি ব্যবসার ব্যাখ্যার চেয়ে বেশি তথ্য চায়, তবে আপনি নেটওয়ার্কের মধ্যেই একটি কমপ্লায়েন্স সমস্যা ডিজাইন করেছেন।
সবচেয়ে বেশি দেখা যাওয়া সমস্যাগুলোর সমাধান করা
সুরক্ষিত গেস্ট WiFi-এর স্ট্যান্ডার্ড বেসলাইন সহজই রয়েছে: আলাদা SSID, ক্লায়েন্ট আইসোলেশন, WPA2 বা WPA3, এবং প্রাইমারি LAN-এ অ্যাক্সেস ব্লক করা। উল্লেখিত নির্দেশিকাটি আরও সতর্ক করে যে আইসোলেশন বাদ দিলে গেস্ট WiFi একটি আসল সিকিউরিটি বাউন্ডারির পরিবর্তে কেবল একটি আলাদা পাসওয়ার্ডে পরিণত হয় । ট্রাবলশুটিং করার সময়, জটিল কেসগুলো দেখার আগে এখান থেকে শুরু করুন।
গেস্টরা কানেক্ট হতে পারছেন কিন্তু ইন্টারনেট নেই
প্রথমে DHCP অ্যালোকেশন চেক করুন, তারপর আপস্ট্রিম ফায়ারওয়াল পলিসি এবং এরপর DNS রিচিবিলিটি চেক করুন। অনেক এস্টেটে, এই সমস্যাটি একটি পলিসি অবজেক্ট বা NAT সেটিং-এর কারণে ঘটে যা স্টেজিংয়ে সঠিক ছিল কিন্তু প্রোডাকশনে বাদ পড়ে গেছে।
Captive Portal দেখা যাচ্ছে না
একাধিক অপারেটিং সিস্টেম দিয়ে পরীক্ষা করুন। কিছু ক্লায়েন্ট পোর্টাল ডিটেকশন ঠিকমতো করতে পারে না, বিশেষ করে যদি SSL ইন্টারসেপশন, কনটেন্ট ফিল্টারিং বা অস্বাভাবিক রিডাইরেকশন সেটিংস জড়িত থাকে। নিশ্চিত করুন যে WLAN ব্যবহারকারীদের সঠিক পোর্টাল হোস্ট-এ পাঠাচ্ছে এবং সার্টিফিকেটের ট্রাস্ট ফ্লোটিকে ব্যাহত করছে না।
গেস্টরা ইন্টারনাল ডিভাইসগুলো দেখতে পাচ্ছেন
এটিকে ব্যবহারকারীর অভিযোগ হিসেবে না দেখে ডিজাইনের ত্রুটি হিসেবে বিবেচনা করুন। অবিলম্বে VLAN অ্যাসাইনমেন্ট, ACL এবং ক্লায়েন্ট আইসোলেশন পর্যালোচনা করুন। এটি সবচেয়ে স্পষ্ট লক্ষণগুলোর একটি যে কেউ কেবল নামেই একটি "গেস্ট" নেটওয়ার্ক তৈরি করেছে।
লেগেসি ডিভাইসগুলো কানেক্ট হবে না
একটি মাত্র ত্রুটিপূর্ণ ডিভাইস ক্লাসের সুবিধার্থে পুরো WLAN-কে দুর্বল করবেন না। সেই ডিভাইসগুলোকে তাদের নিজস্ব ক্রেডেনশিয়াল মডেল এবং রেস্ট্রিক্টেড পলিসি সহ একটি আলাদা অনবোর্ডিং পাথে রাখুন।
একটি সহজ অপারেটিং চেকলিস্ট
একটি পুনরাবৃত্তিযোগ্য রিভিউ সাইকেল ব্যবহার করুন:
- লগ পর্যালোচনা করুন: ব্যর্থ অথেনটিকেশন প্যাটার্ন এবং অস্বাভাবিক ট্রাফিক খুঁজুন।
- আইসোলেশন পুনরায় পরীক্ষা করুন: গেস্টরা এখনও লোকাল রিসোর্সে পৌঁছাতে পারছে না তা নিশ্চিত করুন।
- প্যাচ ইনফ্রাস্ট্রাকচার: AP, কন্ট্রোলার এবং পোর্টাল উপাদানগুলো আপ-টু-ডেট রাখুন।
- গেস্ট জার্নি অডিট করুন: লাইভ অভিজ্ঞতা এখনও পলিসি এবং প্রাইভেসি প্রতিশ্রুতির সাথে মিলছে কিনা তা নিশ্চিত করুন।
- ওয়ার্কঅ্যারাউন্ডগুলো বাদ দিন: কেউ সক্রিয়ভাবে সমর্থন না করা পর্যন্ত সাময়িক ব্যতিক্রমগুলোর মেয়াদ শেষ হওয়া উচিত।
কীভাবে গেস্ট WiFi সেট আপ করতে হয় তা আসলে দুটি কাজ। প্রথমত, বাউন্ডারি সঠিকভাবে তৈরি করুন। তারপর এটিকে একটি প্রোডাকশন সার্ভিসের মতো পরিচালনা করুন।
আপনি যদি শেয়ার করা পাসওয়ার্ড এবং মৌলিক স্প্ল্যাশ পেজের বাইরে গিয়ে চিন্তা করতে চান, তবে আপনার সংক্ষিপ্ত তালিকায় Purple মূল্যায়ন করার মতো একটি সেবা। এটি পাসওয়ার্ডহীন অনবোর্ডিং, Passpoint এবং OpenRoaming সক্ষমতা, ডিরেক্টরি ইন্টিগ্রেশন, অ্যানালিটিক্স, এবং Meraki, Aruba, Ruckus, Mist, এবং UniFi-এর মতো প্ল্যাটফর্মজুড়ে ভেন্ডর ইন্টারঅপারেবিলিটিসহ অতিথি, কর্মী এবং মাল্টি-টেন্যান্ট অ্যাক্সেস সমর্থন করে।
