WiFi-এর জন্য ক্যাপটিভ পোর্টাল: এটি কীভাবে কাজ করে এবং কার এটি প্রয়োজন
WiFi-এর জন্য ক্যাপটিভ পোর্টাল কী, স্থানগুলি কীভাবে এটি ব্যবহার করে, কোন সম্মতির নিয়মগুলি প্রযোজ্য এবং কোন ইন্টিগ্রেশন বিকল্পগুলি আপনার নেটওয়ার্কের জন্য উপযোগী তা জানুন।
যদি একজন গেস্ট আপনার WiFi-এ যুক্ত হতে পারেন এবং অবিলম্বে ব্রাউজ করা শুরু করতে পারেন, তবে তারা ঠিক কীসে সম্মতি দিয়েছিলেন এবং আপনি তাদের সম্পর্কে কী জানতে পেরেছিলেন? এটিই সেই ব্যবধান যা WiFi-এর জন্য একটি ক্যাপটিভ পোর্টাল পূরণ করে, তবে কেবল তখনই যদি আপনি তিনটি কাজ আলাদা করেন যা প্রায়শই একটি স্ক্রিনে তৈরি করা হয়। একটি কাজ নেটওয়ার্ক অ্যাক্সেস নিয়ন্ত্রণ করে। দ্বিতীয়টি আপনার ব্যবহারের শর্তাবলীর গ্রহণযোগ্যতা রেকর্ড করে। তৃতীয়টি মার্কেটিং সম্মতি চায়, এবং এটি অন্য দুটির মতো এক নয়।
একটি ফ্রন্ট ডেস্ক কাউকে ভেতরে আসার অনুমতি দিতে পারে, হাউসের নিয়মগুলি বুঝিয়ে বলতে পারে এবং মেলিং তালিকায় যোগ দেওয়ার জন্য আমন্ত্রণ জানাতে পারে। সেগুলি সম্পর্কিত, তবে একটি সিদ্ধান্ত নয়। ভেন্যুগুলি যখন সেগুলিকে একটি টিক বক্স হিসাবে বিবেচনা করে, তখন অতিথিরা বিভ্রান্ত হন, সম্মতি দুর্বল হয়ে পড়ে এবং যেসব ডিভাইস ব্রাউজার খোলে না সেগুলি পাস করে চলে যেতে পারে বা আটকে যেতে পারে।
সূচিপত্র
- একটি ক্যাপটিভ পোর্টাল পর্যায়ক্রমে যেভাবে কাজ করে
- ভেন্যুগুলি যেখানে ক্যাপটিভ পোর্টাল ব্যবহার করে
- অতিথির ডেটা, সম্মতি এবং যা যা চাওয়া উচিত
- প্রচেষ্টা এবং ডেটার ভিত্তিতে লগইন পদ্ধতির তুলনা
- ক্যাপটিভ পোর্টালগুলি ব্যর্থ হওয়ার কারণ এবং কীভাবে তা প্রতিরোধ করা যায়
- আপনার বিদ্যমান নেটওয়ার্কের সাথে ইন্টিগ্রেশনের বিকল্পসমূহ
- আপনার ভেন্যুর প্রয়োজনীয় পোর্টাল সেটআপটি বেছে নিন
একটি ক্যাপটিভ পোর্টাল কীভাবে পর্যায়ক্রমে কাজ করে
হোটেল অভ্যর্থনা কক্ষের কথা ভাবুন। রুমের চাবি নেওয়ার আগে প্রতিটি অতিথিকে যেমন সেই ডেস্কে থামতে হয়, ঠিক তেমনি WiFi-এ যোগ দেওয়া এবং ইন্টারনেটে পৌঁছানোর মাঝখানে একটি পোর্টাল একইভাবে কাজ করে। অতিথি প্রথমে নেটওয়ার্কে যুক্ত হন, তবে কেবল সেই সংযোগটিই অবাধ ব্রাউজিংয়ের অনুমতি দেয় না।
ধরা যাক কোনও ক্যাফেতে থাকা একজন অতিথি আপনার নেটওয়ার্কের নামে ট্যাপ করেছেন। তাঁর ফোন একটি অ্যাক্সেস পয়েন্টের সাথে সংযুক্ত হয় এবং স্থানীয় নেটওয়ার্ক সেটিংস পায়, তবুও গেটওয়ে তাঁকে একটি সীমিত অবস্থায় রাখে। তিনি যখন ব্রাউজ করার চেষ্টা করেন, তখন সেই অনুরোধটি ইন্টারসেপ্ট করা হয় এবং তিনি যে সাইটের অনুরোধ করেছিলেন তার পরিবর্তে তাঁকে আপনার পোর্টাল পৃষ্ঠায় পুনরায় নির্দেশিত করা হয়।
এটি সেই লেনদেন যা Advantech ক্যাপটিভ পোর্টাল ডকুমেন্টেশনে বর্ণনা করা হয়েছে, যেখানে একজন ব্যবহারকারী একটি উন্মুক্ত বা আংশিক-উন্মুক্ত নেটওয়ার্কে যুক্ত হন এবং একটি পোর্টালে রিডাইরেক্ট হন যা অ্যাক্সেস পাওয়ার আগে শংসাপত্র, অর্থপ্রদান, নিবন্ধন বা শর্তাবলীর গ্রহণযোগ্যতা চাইতে পারে। এরপর তিনি শর্তাবলী মেনে নিয়ে, একটি ইমেল প্রবেশ করিয়ে বা অর্থপ্রদান করে প্রমাণীকরণ করেন। তিনি সেই ধাপটি সম্পন্ন করার পরে, নেটওয়ার্ক তার ডিভাইসটিকে অনুমোদন দেয় এবং সাধারণ ট্র্যাফিক চলতে দেয়।
| ধাপ | কী ঘটে |
|---|---|
| 1. অ্যাসোসিয়েশন | ডিভাইস গেস্ট নেটওয়ার্কে যুক্ত হয় |
| 2. ইন্টারসেপশন | ব্রাউজার অনুরোধ পোর্টাল পৃষ্ঠায় রিডাইরেক্ট করা হয় |
| 3. প্রমানীকরণ | গেস্ট ইমেল প্রবেশ করান, শর্তাবলী স্বীকার করেন বা পেমেন্ট করেন |
| 4. অনুমোদন | নেটওয়ার্ক ডিভাইসটিকে ইন্টারনেট অ্যাক্সেস প্রদান করে |
| 5. সেশন সমাপ্তি | টাইমারের মেয়াদ শেষ হয় এবং ডিভাইস পোর্টালে ফিরে আসে |
একই প্রক্রিয়া বিমানবন্দর বা একটি ছোট ক্যাফেতেও প্রযোজ্য, কারণ পোর্টাল হলো সেই জায়গা যেখানে আপনার নেটওয়ার্ক পলিসি নির্ধারণ করে কে অনলাইনে থাকবে। টাইমারের সময়সীমা শেষ হয়ে গেলে, অথরাইজেশন শেষ হয় এবং ডিভাইসটি আবার পোর্টালে ফিরে আসে।
এই পরীক্ষাটি করে দেখুন: আপনার গেস্ট নেটওয়ার্কে একটি ফোন কানেক্ট করুন, একটি সাধারণ HTTP পেজ খুলুন এবং ব্রাউজিং শুরু করার আগেই লগইন পেজটি আসছে কি না তা নিশ্চিত করুন।
যেখানে ভেন্যুগুলি ক্যাপটিভ পোর্টাল ব্যবহার করে
কেউ স্ক্রিন ডিজাইন করার আগেই আপনার ভেন্যুর ধরন অনুসারে পোর্টালের কাজটি নির্ধারণ করা উচিত। একটি ক্যাফে, একটি হোটেল এবং একটি হাসপাতালের জন্য একই ধরনের লগইন ধাপের প্রয়োজন হয় না এবং সবক্ষেত্রেই একই টেমপ্লেট ব্যবহার করতে বাধ্য করলে বিভিন্ন স্থানে জটিলতা তৈরি হয়।
| ভেন্যু প্রকার | লক্ষ্য | লগইন ধাপ | সাধারণ সেশন দৈর্ঘ্য |
|---|---|---|---|
| ক্যাফে এবং রেস্তোরাঁ | দ্রুত সাইন-ইন এবং গেস্ট লিস্ট | শর্তাবলী প্লাস ঐচ্ছিক ইমেল | ১ থেকে ২ ঘণ্টা |
| হোটেল এবং থাকার জায়গা | রুম বা বুকিংয়ের সাথে লিঙ্কযুক্ত অ্যাক্সেস | বুকিং বা রুম চেক, ভাউচার বা অ্যাক্সেস কোড | থাকার দৈর্ঘ্য |
| রিটেইল সেন্টার | পুনরায় আসা ভিজিটের পরিমাপ করুন | ইমেল বা অ্যাকাউন্ট সাইন-ইন যা পুনরাবৃত্ত অতিথি শনাক্ত করে | ২ থেকে ৪ ঘণ্টা |
| ইভেন্ট, কোওয়ার্কিং বা হাসপাতাল | সময়-সীমাবদ্ধ অ্যাক্সেস | ভাউচার বা অ্যাক্সেস কোড | ইভেন্টের দিন বা বুক করা স্লট |
ক্যাফে, হোটেল এবং রিটেল সেন্টার
ধরা যাক, একজন ক্যাফের অতিথি অর্ডার দেওয়া এবং বসার মধ্যবর্তী সময়ে নেটওয়ার্কে যুক্ত হলেন। তিনি শর্তাবলী এবং একটি ঐচ্ছিক ইমেল বক্স সহ একটি স্ক্রিন দেখতে পান, কানেক্টে ট্যাপ করেন এবং কয়েক সেকেন্ডের মধ্যে অনলাইনে চলে আসেন। এর সাথে আরও পাঁচটি ফিল্ড যোগ করলে তিনি পরিবর্তে মোবাইল ডেটাতে স্যুইচ করবেন।
একটি হোটেলের বিপরীত ঝুঁকি রয়েছে। যদি পোর্টালটি কোনও রুম বা বুকিং যাচাই না করে, তবে লবি বা বাইরের রাস্তায় থাকা যে কেউ অর্থ প্রদানকারী অতিথিদের জন্য নির্দিষ্ট ব্যান্ডউইথ ব্যবহার করতে পারে। খুচরা বিক্রেতা কেন্দ্রগুলি পরিমাপ সংক্রান্ত সমস্যার মুখোমুখি হয়। প্রত্যাবর্তনকারী ডিভাইস বা অ্যাকাউন্ট সনাক্ত করে এমন লজিক না থাকলে, প্রতিটি ভিজিটকে প্রথম ভিজিট বলে মনে হয় এবং বারবার আসা ভিজিটরদের সংখ্যা পরিমাপ করা যায় না।
ইভেন্ট, কোওয়ার্কিং স্পেস এবং হাসপাতাল
এই ভেন্যুগুলি ফর্মের চেয়ে সেশন টাইমার এবং অ্যাক্সেস কোড নিয়ে বেশি চিন্তা করে। একটি ডে পাস, অ্যাপয়েন্টমেন্ট, বা ইভেন্ট টিকিট নির্ধারণ করে যে অ্যাক্সেস কতক্ষণ স্থায়ী হওয়া উচিত। সেই সময়সীমা শেষ হলে, কর্মীদের ম্যানুয়ালি ডিভাইসগুলি না সরিয়েই অ্যাক্সেস সম্পূর্ণরূপে বন্ধ হয়ে যাওয়া উচিত।
আপনার সেটিংস যাই হোক না কেন, শুধুমাত্র একটি লগইন পেজই অতিথিদের নিরাপদ রাখে - এই ধারণা নেওয়ার আগে এই পাবলিক WiFi বিপদগুলির ব্যাখ্যা পর্যালোচনা করা দরকার। একটি পরিচালিত কী দিয়ে সুরক্ষিত কেবল কর্মীদের জন্য তৈরি নেটওয়ার্ক পোর্টাল থেকে কোনও সুবিধা পায় না। এটি কেবল একটি অতিরিক্ত পদক্ষেপ যোগ করে যা আপনার টিমের প্রয়োজন নেই।
নির্দিষ্ট একক ফলাফলটি লিখে রাখুন যা আপনার গেস্ট নেটওয়ার্কের অবশ্যই প্রদান করা উচিত। আপনি সংগ্রহ করতে চান এমন ফিল্ডগুলির তালিকার চেয়ে এই বাক্যটি আপনার লগইন পদ্ধতিটি অনেক ভালভাবে নির্ধারণ করে।
অতিথির ডাটা, সম্মতি এবং কী তথ্য চাওয়া উচিত
অনলাইনে যাওয়ার অর্থ কি ব্যক্তিগত ডেটা তুলে দেওয়া? অনেক ভেন্যু ধরে নেয় যে উত্তরটি হ্যাঁ, এবং তারা যতটা সম্ভব দীর্ঘ ফর্ম তৈরি করে। প্রমাণ বলে যে এটি একটি পছন্দ, কোনও বাধ্যবাধকতা নয়।
৬৭টি পাবলিক WiFi হটস্পটের উপর পরিচালিত একটি ২০১৯ সালের একাডেমিক গবেষণায়, ২৭টি হটস্পট, যা নমুনার ৪০.৩%, ব্যক্তিগত তথ্য সংগ্রহের জন্য সোশ্যাল লগইন বা একটি রেজিস্ট্রেশন পৃষ্ঠা ব্যবহার করেছিল, এবং ১৯টি ক্ষেত্রে ইন্টারনেটে অ্যাক্সেসের জন্য সেই প্রক্রিয়াটি সম্পন্ন করা বাধ্যতামূলক ছিল। একই গবেষণায় দেখা গেছে ৪০টি হটস্পট, বা ৫৯.৭%, স্পষ্ট ব্যক্তিগত তথ্য অনুরোধ না করেই ইন্টারনেট অ্যাক্সেসের অনুমতি দিয়েছে। তাই একটি পোর্টাল থাকা মানেই স্বয়ংক্রিয়ভাবে মার্কেটিং রেজিস্ট্রেশন বোঝায় না।
একটি স্ক্রিনে তিনটি ফাংশন
আপনার ডিজাইন এবং রেকর্ডে এগুলিকে স্পষ্টভাবে আলাদা রাখুন।
- নেটওয়ার্ক অ্যাক্সেস নিয়ন্ত্রণ করা: গেটওয়ে সিদ্ধান্ত নেয় যে এই ডিভাইসটি ইন্টারনেটে পৌঁছাতে পারবে কিনা।
- ব্যবহারের শর্তাবলী দেখানো: অতিথি সংযোগের জন্যই গ্রহণযোগ্য-ব্যবহারের শর্তাবলী স্বীকার করে নেন।
- মার্কেটিং সম্মতি নেওয়া: অতিথি পরবর্তীতে বার্তা পেতে সম্মত হন, যা একটি পৃথক সিদ্ধান্ত।
পাঠকরা সবচেয়ে বেশি যে বিষয়টি মিস করেন তা এখানে দেওয়া হল। কেবলমাত্র একটি স্পষ্ট অপ্ট-ইনকেই মার্কেটিং সম্মতি হিসাবে ধরা হয়; WiFi শর্তাবলী স্বীকার করলেই তা মার্কেটিং সম্মতি প্রদান করে না। অনলাইনে অ্যাক্সেস পেতে টিক দেওয়া একজন অতিথি আপনার নিউজলেটারে সম্মত হননি। সেই টিকটিকে অনুমতি হিসাবে গণ্য করা আপনার তালিকা এবং আপনার সুনামকে ঝুঁকিতে ফেলে।
একটি লেআউট যা অতিথিরা সহজেই বুঝতে পারেন
ব্যবহারের গ্রহণযোগ্যতার শর্তাবলীর পাশে একটি প্রয়োজনীয় শর্তাবলীর টিক রাখুন। এর নীচে, নিজস্ব স্পষ্ট বাক্য সহ একটি পৃথক, টিক না দেওয়া মার্কেটিং চেক বক্স দিন, যেমন ইমেলের মাধ্যমে অফার পাওয়ার একটি আমন্ত্রণ। একটি দৃশ্যমান গোপনীয়তা বিজ্ঞপ্তি লিঙ্ক যোগ করুন যা অতিথি কিছু জমা দেওয়ার আগেই খোলে, সাইন-ইনের পরে অস্পষ্টভাবে রাখা থাকে না।
এই পৃথকীকরণ ভেন্যুগুলির জন্য এই GDPR কমপ্লায়েন্ট ইমেল মার্কেটিং চেকলিস্টে উল্লিখিত ব্যবহারিক পরীক্ষাগুলির সাথে সামঞ্জস্যপূর্ণ। এটি অতিথিদের একটি প্রকৃত পছন্দও দেয়। কেউ মার্কেটিং প্রত্যাখ্যান করলেও অনলাইনে অ্যাক্সেস পেতে পারেন, যা ঠিক যেভাবে কাজ করা উচিত।
অতিরিক্ত ফিল্ড মানেই অতিরিক্ত সুবিধা নয়। প্রতিটি অতিরিক্ত প্রশ্ন লগইন সম্পূর্ণ করার সংখ্যা কমায় এবং আপনার উপর সুরক্ষার দায়িত্ব থাকা ডাটার পরিমাণ বাড়ায়।
যখন একজন অতিথি অপ্ট-ইন করেন, তখন পোর্টালটি একটি কেন্দ্রীয় রেকর্ডে তাদের ইমেল, ভিজিটের তারিখ এবং পছন্দের অবস্থান সংরক্ষণ করতে পারে। যখন একজন অতিথি সংযোগ স্থাপন করেন এবং তাদের ইমেল ঠিকানা বা সোশ্যাল প্রোফাইল ব্যবহার করে লগ ইন করেন, আমরা সেই ডেটা ক্যাপচার করি এবং একটি কেন্দ্রীভূত CRM-এ সংরক্ষণ করি। এইভাবে একটি ভেন্যু কোনও প্ল্যাটফর্মের দর্শকদের ওপর নির্ভর না করে নিজস্ব ফার্স্ট-পার্টি ডেটা তৈরি করে।
লঞ্চের আগে তিনটি প্রশ্নের উত্তর দিন। অ্যাক্সেস দেওয়ার জন্য ঠিক কী ডেটা প্রয়োজন? আপনি কতক্ষণ পরিচয় এবং ডিভাইসের রেকর্ড রাখবেন? একজন অতিথি কি মার্কেটিং প্রত্যাখ্যান করেও অনলাইনে অ্যাক্সেস পেতে পারেন? যদি কোনও উত্তর অস্পষ্ট হয়, তবে ডিজাইন ঠিক করার আগে ফর্মটি ঠিক করুন।
প্রচেষ্টা এবং ডাটার ভিত্তিতে লগইন পদ্ধতির তুলনা
প্রতিটি লগইন পদ্ধতি অতিথির প্রচেষ্টা-র বিপরীতে সংগৃহীত ডেটা এবং বিভিন্ন ডিভাইসে এর নির্ভরযোগ্যতার মধ্যে ভারসাম্য বজায় রাখে। টেবিলটি ওপর থেকে নিচে পড়লে আপনি দেখতে পাবেন যে কিভাবে এই ভারসাম্য ধাপে ধাপে পরিবর্তিত হচ্ছে।
| লগইন পদ্ধতি | সংগৃহীত ডেটা | অতিথির প্রচেষ্টা | সবচেয়ে উপযুক্ত |
|---|---|---|---|
| শুধুমাত্র শর্তাবলীতে ক্লিক-থ্রু | শুধুমাত্র ডিভাইসের রেকর্ড | খুব কম | দ্রুত অ্যাক্সেস দিতে চাওয়া ক্যাফেগুলি |
| ভাউচার বা অ্যাক্সেস কোড | শুধুমাত্র কোড রিডেম্পশন | কম | মুদ্রিত বা পেইড অ্যাক্সেস সহ হোটেল এবং ইভেন্ট |
| ইমেল রেজিস্ট্রেশন | ইমেল ঠিকানা এবং মার্কেটিং অপ্ট-ইন | মাঝারি | গেস্ট লিস্ট তৈরি করছে এমন ভেন্যুসমূহ |
| সোশ্যাল লগইন | প্রোভাইডার অনুমতি দেয় এমন প্রোফাইল ডেটা | কম | যেসব অতিথি এক-ট্যাপ সাইন-ইন পছন্দ করেন |
| SMS ওয়ান-টাইম কোড | মোবাইল নম্বর | মাঝারি | যেসব ভেন্যুর যাচাইকৃত পরিচয় প্রয়োজন |
| Passpoint বা শংসাপত্র-ভিত্তিক প্রমাণীকরণ | ডিভাইস শংসাপত্র, কোনো পোর্টাল পৃষ্ঠা নেই | সেটআপের পরে অত্যন্ত কম | ম্যানেজ করা ডিভাইস সহ বড় ভেন্যুসমূহ |
সবচেয়ে কম ডেটা থেকে সবচেয়ে বেশি ডেটা
শুধুমাত্র শর্তাবলী-সম্পর্কিত ক্লিক-থ্রু একটি মাত্র ট্যাপের অনুরোধ করে এবং কেবল একটি ডিভাইস রেকর্ড তৈরি করে। এটি দ্রুত হলেও কোনো গেস্ট তালিকা তৈরি করতে পারে না। একটি ভাউচার বা অ্যাক্সেস কোড অতিথি কে তা না জেনেই নিয়ন্ত্রণ যোগ করে, যা প্রিন্ট করা হোটেল কার্ড এবং ইভেন্ট পাসগুলির জন্য সুবিধাজনক।
ইমেল রেজিস্ট্রেশনে বেশি প্রচেষ্টার প্রয়োজন হয় এবং এটি ব্যবহারের যোগ্য একটি পরিচিতি এনে দেয়, যদি মার্কেটিং অপ্ট-ইন আলাদা থাকে। আপনি যদি এটিকে অন্যান্য তথ্য সংগ্রহের বিষয়ের সাথে তুলনা করে দেখেন, তবে ইমেল সংগ্রহের জন্য QR কোড সাইন-আপ বনাম WiFi লগইনের এই তুলনাটি আপনাকে ডেটার গুণমানের বিপরীতে প্রচেষ্টার মূল্যায়ন করতে সাহায্য করে।
সোশ্যাল লগইন এক ট্যাপিংয়ের মতো মনে হলেও, এটি একটি থার্ড-পার্টি রিডাইরেক্ট যোগ করে। কিছু ব্রাউজার এবং যে ছোট সাইন-ইন উইন্ডোগুলি ফোনসমূহ WiFi এর জন্য ব্যবহার করে, সেগুলি এই রিডাইরেক্টগুলি সঠিকভাবে পরিচালনা করতে পারে না, এবং অতিথিদের হয়তো সেই পাসওয়ার্ড মনে নাও থাকতে পারে যা তারা বছরের পর বছর ধরে টাইপ করেননি। SMS এক-কালীন কোডগুলি একটি নম্বর যাচাই করে, কিন্তু এগুলি অতিথির মোবাইলে সিগন্যাল থাকার এবং বার্তা গ্রহণ করতে পারে এমন একটি নম্বর থাকার ওপর নির্ভর করে।
Passpoint বা সার্টিফিকেট-ভিত্তিক প্রমাণীকরণ সেটআপের পরে পোর্টাল পৃষ্ঠাটিকে সরিয়ে দেয়। এটির জন্য ডিভাইসে একটি পরিচালিত প্রোফাইল প্রয়োজন, তাই এটি প্রথমবার আপনার নেটওয়ার্ক ব্যবহার করা ভিজিটরদের চেয়ে কর্মী এবং নিয়মিত ফিরে আসা অতিথিদের ক্ষেত্রে বেশি উপযুক্ত।
সিদ্ধান্তের নিয়ম: লগইন ধাপটিকে আপনার প্রয়োজনীয় একটি ফলাফলের সাথে মেলান, আপনার সংগ্রহ করা সর্বাধিক ফিল্ডের সাথে নয়।
এখনই দুটি পদ্ধতি সংক্ষিপ্ত তালিকাভুক্ত করুন। চূড়ান্ত একটি বাছাই করার আগে আপনি আপনার হার্ডওয়্যার এবং ব্যর্থতা চেকের বিরুদ্ধে উভয়ই পরীক্ষা করবেন।
কেন ক্যাপটিভ পোর্টাল ব্যর্থ হয় এবং কীভাবে এটি প্রতিরোধ করবেন
একটি পোর্টাল কেবল একটি ব্র্যান্ডেড পেজ নয়। লগইন করার আগে, গেটওয়ে প্রতিটি ডিভাইসকে একটি সীমাবদ্ধ অবস্থায় রাখে এবং কেবল ডিসকভারি, লগইন এবং পোর্টাল ট্রাফিকের অনুমতি দেয়। অধিকাংশ ব্যর্থতা ঘটে কারণ সেই সীমাবদ্ধ এলাকাটি সঠিকভাবে তৈরি বা পরীক্ষা করা হয় না।
চারটি লক্ষণ যা অতিথিদের চোখে পড়ে
পোর্টালটি কখনোই দৃশ্যমান হয় না। বেশিরভাগ সাইট এখন HTTPS ব্যবহার করে এবং ব্রাউজারগুলি প্রতিস্থাপিত শংসাপত্রগুলি প্রত্যাখ্যান করে, তাই পুরানো HTTP ইন্টারসেপশন বিশ্বস্তভাবে আপনার পৃষ্ঠা প্রদর্শন করতে পারে না। অপারেটিং সিস্টেমগুলি তার পরিবর্তে সংযোগ পরীক্ষা চালায়, যেমন TCP পোর্ট 80 এবং 443 এর মাধ্যমে captive.apple.com-এ পাঠানো অনুরোধ যা Apple-এর ক্যাপটিভ নেটওয়ার্ক সাপোর্ট গাইডেন্সে বর্ণনা করা হয়েছে, ইন্টারনেট অ্যাক্সেস ইন্টারসেপ্ট করা হচ্ছে কিনা তা শনাক্ত করতে।
পেজটি সঠিকভাবে লোড হচ্ছে না। HTML চাওয়া হলেও, রেস্ট্রিক্টেড স্টেটের ভিতরে স্টাইলশীট, স্ক্রিপ্ট, ফন্ট বা আইডেন্টিটি-প্রোভাইডার রিডাইরেক্টগুলি ব্লক করা হয়েছে। পোর্টাল অ্যাসেটগুলি স্থানীয়ভাবে হোস্ট করুন অথবা পেজটির জন্য প্রয়োজনীয় প্রতিটি অ্যান্ডপয়েন্টকে অ্যালাউলিস্ট করুন।
কিছু অতিথি পোর্টাল বাইপাস করেন। আপনি যদি IPv4 ফিল্টার করেন কিন্তু IPv6 উন্মুক্ত রাখেন, তবে ট্র্যাফিক আপনার নিয়ম অতিক্রম করতে পারে। উভয় পথেই সমান ব্যবস্থা প্রয়োগ করুন।
অতিথিরা বারবার লগইনে ফিরে আসছেন। অথরাইজেশনের সময়সীমা শেষ হয়ে গেছে, বা অ্যাক্সেস পয়েন্টগুলির মধ্যে রোমিং সেশনটিকে ড্রপ করছে এবং অতিথিকে বারবার রিডাইরেক্ট করা হচ্ছে। এটি সিগন্যাল শক্তিশালী থাকলেও WiFi বিচ্ছিন্ন বা ত্রুটিপূর্ণ হিসেবে প্রতিফলিত হয়।
লঞ্চ করার আগে যে পরীক্ষাগুলি চালানো উচিত
- বাস্তব ডিভাইস পরীক্ষা করুন: iOS, Android, Windows, macOS, এবং প্রিন্টার বা টিভির মতো অন্তত একটি IoT ডিভাইসের মাধ্যমে কাজ পরীক্ষা করুন।
- দুটি সময় পরিমাপ করুন: প্রতিটি ডিভাইসে পোর্টালে আসার সময় এবং অনুমোদনের সময় রেকর্ড করুন।
- সেশন মেয়াদ শেষ করতে বাধ্য করুন: নিশ্চিত করুন যে গেস্ট পোর্টালে সঠিকভাবে ফিরে আসেন এবং আবার সাইন ইন করতে পারেন।
- সংযুক্ত থাকা অবস্থায় রোম করুন: একটি প্রাইভেট MAC ঠিকানা সক্ষম রেখে অ্যাক্সেস পয়েন্টগুলির মধ্যে হাঁটুন এবং অ্যাক্সেস সক্রিয় থাকে কিনা তা লক্ষ্য করুন।
পোর্টাল শনাক্তকরণ ব্যর্থ হলে ব্যবহারের জন্য একটি ডকুমেন্টেড ফলব্যাক রাখুন, যেমন একটি ছোট ঠিকানা যা কর্মীরা ম্যানুয়ালি খোলার জন্য অতিথিদের দিতে পারেন। নেটওয়ার্ক সম্পূর্ণরূপে ওপেন করে নিরাপত্তা দুর্বল করবেন না।
অবশেষে, অতিথিদের ফিশিং সনাক্ত করতে সহায়তা করুন। নেটওয়ার্কের নামটি ভেন্যুর সাথে মেলা উচিত, পোর্টালের ঠিকানাটি ভেন্যুর নিজস্ব ডোমেনে থাকা উচিত এবং ব্রাউজারে সেই ডোমেনের জন্য একটি বৈধ TLS সার্টিফিকেট দেখানো উচিত। একটি বৈধ পোর্টাল কখনও ব্যাঙ্ক বিবরণ বা সোশ্যাল মিডিয়া পাসওয়ার্ড চায় না।
আপনার বিদ্যমান নেটওয়ার্কের সাথে ইন্টিগ্রেশন অপশনসমূহ
একটি পোর্টাল যোগ করার জন্য আপনাকে আপনার নেটওয়ার্ক নতুন করে তৈরি করতে হবে না। ডিভাইসগুলি কীভাবে জানতে পারে যে পোর্টাল রয়েছে তা দিয়ে শুরু করুন, কারণ এটি সেই ফোনগুলির নির্ভরযোগ্যতা নির্ধারণ করে যেগুলি কখনই প্রথমে ব্রাউজার খোলে না।
নিচের ছবিটি দেখাচ্ছে কীভাবে পোর্টালটি আপনার অ্যাক্সেস পয়েন্ট এবং গেস্ট রেকর্ড গ্রহণকারী সিস্টেমগুলির মাঝে কাজ করে।
মানসম্মত পাথ
Fortinet-এর ক্যাপটিভ পোর্টাল অ্যাডমিনিস্ট্রেশন গাইডে বর্ণিত পদ্ধতির অধীনে, RFC 8910 সংজ্ঞায়িত করে কিভাবে একটি নেটওয়ার্ক DHCPv4 অপশন 114, DHCPv6, বা IPv6 রাউটার বিজ্ঞাপনের মাধ্যমে তার পোর্টাল API এন্ডপয়েন্ট প্রচার করে। RFC 8908 এরপর application/captive+json মিডিয়া টাইপ ব্যবহার করে একটি HTTPS JSON API নির্দিষ্ট করে, যা ক্লায়েন্ট এখনও ক্যাপটিভ আছে কিনা, ব্যবহারকারী-মুখী লগইন URI এবং অবশিষ্ট অ্যাক্সেসের সময়ের মতো সেশন তথ্য প্রদর্শন করে।
সহজ কথায়, নেটওয়ার্কটি সরাসরি অপারেটিং সিস্টেমকে বলে যে কোথায় সাইন ইন করতে হবে এবং অ্যাক্সেস কতক্ষণ স্থায়ী হবে। এটি ব্যর্থ রিডাইরেক্টের ওপর নির্ভরতা কমায়, বিশেষ করে যখন অ্যাপগুলি HTTPS বা সার্টিফিকেট পিনিং ব্যবহার করে। API এন্ডপয়েন্ট এবং পোর্টাল উভয়কেই সার্টিফিকেট ভ্যালিডেশন সহ TLS ব্যবহার করতে হবে, অন্যথায় একজন আক্রমণকারী একটি অনুমোদিত স্টেট জাল করতে পারে বা লগইন গন্তব্য পরিবর্তন করতে পারে।
এই সংক্ষিপ্ত ভিডিওটি ব্যাখ্যা করে যে কীভাবে সেই ইন্টিগ্রেশন পয়েন্টগুলি বাস্তবে একসাথে কাজ করে।
প্রতিটি কানেকশন পয়েন্ট চিহ্নিত করুন
একটি পোর্টাল লেয়ার আপনার বিদ্যমান হার্ডওয়্যারের উপরে থাকতে পারে, যার মধ্যে রয়েছে Cisco Meraki, HPE Aruba, এবং Ubiquiti UniFi, এবং এটি আপনার সাইন-ইনগুলিতে ডেডিকেটেড WiFi প্ল্যাটফর্ম সহ বা ছাড়া চলতে পারে। আপনার IT লিডের উচিত সেটিংস বেছে নেওয়ার আগে চারটি পয়েন্ট ম্যাপ করা।
- অ্যাক্সেস পয়েন্ট কন্ট্রোলার: নেটওয়ার্কের নাম, সীমাবদ্ধ রাজ্য এবং রিডাইরেক্ট বা API বিজ্ঞাপন মালিকানা ধারণ করে।
- আইডেন্টিটি উৎস: রুম নম্বর, ভাউচার, কর্মী অ্যাকাউন্ট বা সোশ্যাল সাইন-ইন পরীক্ষা করে।
- গেস্ট রেকর্ড সিস্টেম: সম্মতিপ্রাপ্ত যোগাযোগের বিবরণ প্রাপ্ত করে, যা উপলব্ধ Purple WiFi ইন্টিগ্রেশন জুড়ে দেখানো হয়েছে।
- TLS সার্টিফিকেট: অতিথিরা যে পোর্টাল ডোমেন দেখতে পান তার সাথে মিল থাকতে হবে, যার নবায়নের দায়িত্ব একজন নির্দিষ্ট ব্যক্তির থাকে।
একটি ডিসিশন টেস্ট পরিচালনা করুন। যদি আপনার নেটওয়ার্ক IPv4 এবং IPv6 এ RFC 8910 অ্যাডভার্টাইজমেন্ট সাপোর্ট করে, তবে এটি বজায় রাখুন এবং JSON রেসপন্সগুলি পরীক্ষা করুন। যদি না করে, তবে ডকুমেন্টেড ফলব্যাক সহ ব্রাউজার-ভিত্তিক রিডাইরেক্টের পরিকল্পনা করুন।
আপনার ভেন্যু অনুযায়ী পোর্টাল সেটআপ বেছে নিন
একটি সাইন-ইন স্ক্রিনের পেছনে তিনটি আলাদা সিদ্ধান্ত লুকিয়ে থাকে: নেটওয়ার্ক অ্যাক্সেস, শর্তাবলী মেনে নেওয়া এবং মার্কেটিংয়ের সম্মতি। অ্যাক্সেস ডিভাইসটিকে নেটওয়ার্কে যুক্ত করে। শর্তাবলী মেনে নেওয়া থেকে রেকর্ড হয় যে অতিথি আপনার নিয়মাবলীতে সম্মত হয়েছেন। মার্কেটিং সম্মতি হল একটি স্বেচ্ছায় দেওয়া অপ্ট-ইন, এবং WiFi শর্তাবলী মেনে নেওয়ার অর্থ এটি মঞ্জুর করা নয়। যে সেটআপে এই তিনটি বিষয়কে একটি টিকচিহ্নে একত্র করা হয়, তা এমন সম্মতি সংগ্রহ করে যা আপনি ব্যবহার করতে পারবেন না বা এমন অতিথিদের ব্লক করে যারা আনন্দের সাথে লগ ইন করতেন।
তিনটি শুরুর বিন্দু
যে ক্যাফেগুলির দ্রুত অ্যাক্সেস এবং একটি অপ্ট-ইন তালিকা প্রয়োজন, তাদের শর্তাবলীর সাথে ঐচ্ছিক ইমেল ব্যবহার করা উচিত। অতিথি যখন সক্রিয়ভাবে সেগুলি নির্বাচন করেন কেবল তখনই ইমেল ক্ষেত্র এবং মার্কেটিং অপ্ট-ইন দৃশ্যমান হয়। প্রথমে অতিথি রেকর্ড সিস্টেমটি পরীক্ষা করুন, যাতে নতুন পরিচিতিগুলি কোনো দরকারী জায়গায় সংরক্ষিত হয়।
বুকিংয়ের সাথে অ্যাক্সেস সংযুক্ত করছে এমন একটি হোটেলের রুম বা বুকিং চেক, অথবা চেক-ইন করার সময় প্রদত্ত ভাউচার ব্যবহার করা উচিত। অ্যাক্সেস অথরাইজ করার জন্য প্রয়োজনীয় স্টে রেফারেন্স সংগ্রহ করুন, কোনো অতিরিক্ত প্রোফাইল ফিল্ড নয়। প্রথমে পরিচয়ের উৎস চেক করুন, কারণ ফ্রন্ট ডেস্ক কর্মীরা অমিলগুলির সমাধান করবেন।
যেসব বহু-সাইট গ্রুপের ধারাবাহিকতা প্রয়োজন, তাদের সমস্ত সাইট জুড়ে একটি সম্মতি রেকর্ড এবং রিপোর্টিং মানসম্মত করা উচিত। সব জায়গায় একই আলাদা অপ্ট-ইন সহ ইমেল রেজিস্ট্রেশনের অর্থ হলো প্রতিটি সাইট একইভাবে প্রত্যাখ্যান হ্যান্ডেল করে। প্রথমে রিপোর্টিং এবং ডেটা ধরে রাখা (রিটেনশন) পরীক্ষা করে নিন।
যে ডিভাইসগুলি পোর্টাল কখনো দেখবে না
একটি ক্যাপটিভ পোর্টাল কেবল সেই ধরনের হার্ডওয়্যারে কাজ করে যা একটি ব্রাউজার খুলতে পারে। স্মার্ট টিভি, প্রিন্টার, টিল টার্মিনাল এবং ইন-রুম গ্যাজেটগুলিতে পৃষ্ঠা রেন্ডার করার মতো কিছু থাকে না, তাই সেগুলি অনির্দিষ্টকালের জন্য সীমিত অবস্থায় আটকে থাকে। সেইসব ডিভাইসগুলিকে একটি পৃথক পাথ দিন, যেমন স্টাফ বা ডিভাইস নেটওয়ার্কে প্রতি-ডিভাইস কী (keys), এবং লগইন দেখাতে সক্ষম ফোন এবং ল্যাপটপের জন্য পোর্টালটিকে সংরক্ষিত রাখুন।
লঞ্চ করার আগে, নিশ্চিত করুন যে আপনার হার্ডওয়্যার স্ট্যান্ডার্ডস পাথ সাপোর্ট করে বা আপনার ফলব্যাক ডকুমেন্টেড রয়েছে। শুধুমাত্র অফিসের ল্যাপটপ নয়, প্রকৃত অতিথি ডিভাইসগুলির সাহায্যে ডিভাইস, এক্সপায়ারি, রোমিং এবং IPv6 সংক্রান্ত চেকগুলি চালান।
Purple Engage সেই সকল ভেন্যুর জন্য উপযুক্ত যেগুলি চায় যে সাইন-ইন ডেটা পরবর্তী মার্কেটিং কাজে লাগুক। এটি ফিজিক্যাল স্পেসের জন্য একটি অল-ইন-ওয়ান মার্কেটিং সিস্টেম যা প্রতিটি WiFi সাইন-ইনকে Purple WiFi সহ বা ছাড়া পুনরায় ভিজিটে পরিণত করে এবং কোন ক্যাম্পেইনটি এটি সফল করেছে তা প্রমাণ করে। এটি ইমেল দ্বারা মিলে যাওয়া একটি একক গেস্ট রেকর্ডে WiFi সাইন-ইন, টিল সেলস, বুকিং, ফর্ম, ফাইল, মেসেজ এবং সার্ভের উত্তরগুলিকে একত্রিত করে। যেহেতু এটি Purple WiFi সহ বা ছাড়া কাজ করে এবং আপনার বিদ্যমান সিস্টেমগুলি পড়তে পারে, আপনি এটিকে ইতিমধ্যেই ব্যবহার করা হার্ডওয়্যার এবং টিলগুলির সাথে সংযুক্ত করতে পারেন।
এই সপ্তাহে একটি কাজ করুন। আপনার পোর্টালের মাধ্যমে যে একক ফলাফলটি নিশ্চিত করতে চান তা লিখে রাখুন, তারপর আপনার লগইন পদ্ধতি, ডাটা ফিল্ড এবং প্রথম ইন্টিগ্রেশন চেক সেই ফলাফলের সাথে সাজান।
আপনি যদি WiFi-এর জন্য একটি ক্যাপটিভ পোর্টাল সেট আপ করেন এবং সম্মতিযুক্ত প্রতিটি সাইন-ইনকে একটি ব্যবহারের যোগ্য গেস্ট রেকর্ডে পরিণত করতে চান, তবে Purple Engage এক জায়গায় WiFi সাইন-ইনগুলির সাথে ক্যাশ কাউন্টারের বিক্রি, বুকিং, ফর্ম এবং সমীক্ষার উত্তর একত্রিত করে। আপনি যে হার্ডওয়্যারগুলি ইতিমধ্যেই ব্যবহার করছেন সেগুলিতে এটি কীভাবে কাজ করে এবং কীভাবে একটি প্রথম সংযোগকে পুনরাবৃত্তি ভিজিটে পরিণত করতে সাহায্য করে তা দেখতে সাইটটি দেখুন।