WiFi স্প্ল্যাশ পেজ কী?

WiFi স্প্ল্যাশ পেজ কী? — একটি Purple ইন্টেলিজেন্স ব্রিফিং [ইন্ট্রো — আনুমানিক ১ মিনিট] Purple ইন্টেলিজেন্স ব্রিফিংয়ে স্বাগতম। আমি আপনাদের হোস্ট, এবং আজ আমরা এমন কিছু নিয়ে আলোচনা করছি যা নেটওয়ার্ক ইনফ্রাস্ট্রাকচার এবং কাস্টমার এক্সপেরিয়েন্সের ঠিক সংযোগস্থলে অবস্থিত: WiFi স্প্ল্যাশ পেজ। এখন, আপনি যদি একজন আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট বা ভেন্যু অপারেশন ডিরেক্টর হন, তবে আপনি প্রায় নিশ্চিতভাবেই এর কোনো একটি ডিপ্লয় করেছেন — বা করতে যাচ্ছেন। কিন্তু স্প্ল্যাশ পেজ আসলে কী, এটি কীভাবে Captive Portal থেকে আলাদা, এবং সবচেয়ে গুরুত্বপূর্ণ হলো, একটি সু-ডিজাইন করা স্প্ল্যাশ পেজ কীভাবে এমন একটি পেজ থেকে আলাদা যা নীরবে আপনার গেস্ট এক্সপেরিয়েন্স নষ্ট করে এবং কমপ্লায়েন্স ঝুঁকি তৈরি করে, তা নিয়ে মার্কেটে আশ্চর্যজনক পরিমাণ বিভ্রান্তি রয়েছে। তাহলে চলুন শুরু করা যাক। আগামী দশ মিনিটে, আমি আপনাদের টেকনিক্যাল আর্কিটেকচার, মূল ডিজাইন সিদ্ধান্ত, হসপিটালিটি এবং রিটেইল থেকে রিয়েল-ওয়ার্ল্ড ডিপ্লয়মেন্ট সিনারিও এবং নির্দিষ্ট কিছু ফাঁদ সম্পর্কে জানাব যা এমনকি অভিজ্ঞ টিমগুলোকেও বিপদে ফেলে। শেষে, আপনার নিজস্ব ডিপ্লয়মেন্ট মূল্যায়ন বা রিডিজাইন করার জন্য আপনার কাছে একটি পরিষ্কার ফ্রেমওয়ার্ক থাকবে। [টেকনিক্যাল ডিপ-ডাইভ — আনুমানিক ৫ মিনিট] চলুন মৌলিক বিষয়গুলো দিয়ে শুরু করি। একটি WiFi স্প্ল্যাশ পেজ — যাকে কখনো কখনো গেস্ট WiFi ল্যান্ডিং পেজ বা WiFi লগইন পেজ বলা হয় — হলো ওয়েব-ভিত্তিক ইন্টারফেস যা একজন ইউজার প্রথমবার গেস্ট ওয়্যারলেস নেটওয়ার্কে কানেক্ট করে ব্রাউজার খুললে দেখতে পান। এটি আপনার গেস্ট WiFi এক্সপেরিয়েন্সের প্রধান দরজা। কিন্তু এখানেই পরিভাষাগুলো গুলিয়ে যায়। একটি স্প্ল্যাশ পেজ এবং Captive Portal এক জিনিস নয়, যদিও সাধারণ কথাবার্তায় দুটি শব্দ একে অপরের পরিপূরক হিসেবে ব্যবহৃত হয়। আমাকে এই বিষয়ে সুনির্দিষ্ট হতে দিন, কারণ আর্কিটেকচারালি এটি গুরুত্বপূর্ণ। একটি Captive Portal হলো নেটওয়ার্ক-লেয়ার মেকানিজম — ইনফ্রাস্ট্রাকচার কম্পোনেন্ট যা আনঅথেনটিকেটেড HTTP ট্রাফিক ইন্টারসেপ্ট করে, একটি DNS রিডাইরেক্ট পারফর্ম করে এবং অথেনটিকেশন সম্পন্ন না হওয়া পর্যন্ত ডিভাইসটিকে একটি সীমাবদ্ধ নেটওয়ার্ক স্টেটে আটকে রাখে। এটি OSI মডেলের লেয়ার দুই এবং লেয়ার তিনে কাজ করে। এর মধ্যে আপনার অ্যাক্সেস কন্ট্রোলার, আপনার RADIUS সার্ভার (যদি আপনি 802.1X রান করেন), আপনার VLAN কনফিগারেশন এবং আপনার DNS রিভলভার অন্তর্ভুক্ত থাকে। Captive Portal হলো গেটকিপার। বিপরীতভাবে, স্প্ল্যাশ পেজ হলো প্রেজেন্টেশন লেয়ার — ওয়েব পেজ যা Captive Portal ইউজারকে পরিবেশন করে। এটি হলো HTML, CSS এবং JavaScript যা গেস্ট আসলে দেখে এবং যার সাথে ইন্টারঅ্যাক্ট করে। এতে আপনার ব্র্যান্ডিং, আপনার অথেনটিকেশন অপশন, আপনার ডেটা ক্যাপচার ফর্ম, আপনার GDPR সম্মতি মেকানিজম এবং আপনার টার্মস অফ সার্ভিস থাকে। তাই সহজ কথায় বলতে গেলে: Captive Portal হলো তালা; স্প্ল্যাশ পেজ হলো দরজা। আপনার উভয়েরই প্রয়োজন, কিন্তু তারা মৌলিকভাবে ভিন্ন কাজ করে, এবং তারা ভিন্ন ভিন্ন টিম দ্বারা পরিচালিত হয় — নেটওয়ার্ক ইঞ্জিনিয়াররা পোর্টাল ইনফ্রাস্ট্রাকচার পরিচালনা করে, যেখানে মার্কেটিং এবং আইটি যৌথভাবে স্প্ল্যাশ পেজ এক্সপেরিয়েন্স পরিচালনা করে। এখন, টেকনিক্যালি এটি কীভাবে কাজ করে? যখন কোনো ডিভাইস আপনার গেস্ট SSID-এর সাথে কানেক্ট হয়, তখন এটিকে একটি সীমাবদ্ধ VLAN-এ রাখা হয় — চলুন একে প্রি-অথেনটিকেশন VLAN বলি। DNS কোয়েরিগুলো ইন্টারসেপ্ট করা হয় এবং আপনার Captive Portal কন্ট্রোলারের IP অ্যাড্রেসে রিভলভ করা হয়। যেকোনো HTTP রিকোয়েস্ট — এবং খেয়াল রাখবেন, এই কারণেই শুধুমাত্র-HTTPS ব্রাউজিং Captive Portal শনাক্তকরণের জন্য কিছু আকর্ষণীয় চ্যালেঞ্জ তৈরি করেছে — একটি 302 রেসপন্সের মাধ্যমে স্প্ল্যাশ পেজ URL-এ রিডাইরেক্ট করা হয়। ডিভাইসের অপারেটিং সিস্টেমে, তা iOS, Android বা Windows যাই হোক না কেন, একটি Captive Portal ডিটেকশন মেকানিজম বিল্ট-ইন থাকে। অ্যাপল ডিভাইসগুলো captivenetwork.apple.com-এ পিং করে; Android ডিভাইসগুলো connectivitycheck.gstatic.com-এ হিট করে। যখন সেই রিকোয়েস্টগুলো একটি অপ্রত্যাশিত রেসপন্স রিটার্ন করে, তখন OS বুঝতে পারে যে এটি একটি Captive Portal-এর পেছনে আছে এবং স্বয়ংক্রিয়ভাবে লগইন প্রম্পট সামনে নিয়ে আসে। ইউজার স্প্ল্যাশ পেজ ফ্লো সম্পন্ন করার পর — তা ইমেইল অ্যাড্রেস এন্টার করা হোক, সোশ্যাল লগইনের মাধ্যমে অথেনটিকেট করা হোক, শর্তাবলী গ্রহণ করা হোক বা ভাউচার কোড এন্টার করা হোক — Captive Portal কন্ট্রোলার তার অথেনটিকেশন টেবিলে ডিভাইসের MAC অ্যাড্রেস বা IP অ্যাড্রেস আপডেট করে, এটিকে পোস্ট-অথেনটিকেশন VLAN-এ নিয়ে যায় এবং সম্পূর্ণ ইন্টারনেট অ্যাক্সেস প্রদান করে। সেশনটি ট্র্যাক করা হয়, সাধারণত একটি কনফিগারেবল টাইমআউট এবং ব্যান্ডউইথ পলিসি প্রয়োগ করার মাধ্যমে। এখন অথেনটিকেশন পদ্ধতিগুলো নিয়ে কথা বলা যাক, কারণ এখানেই ব্যবসায়িক ভ্যালু সত্যিই আলাদা হতে শুরু করে। আপনার কাছে বেশ কয়েকটি অপশন আছে। সবচেয়ে সহজ হলো একটি ক্লিক-থ্রু — ইউজার শুধু শর্তাবলী গ্রহণ করে এবং অ্যাক্সেস পায়। কোনো ডেটা ক্যাপচার হয় না, ন্যূনতম বাধা, কিন্তু ব্যবসার জন্যও ন্যূনতম ভ্যালু। এর এক ধাপ ওপরে হলো ইমেইল রেজিস্ট্রেশন, যেখানে আপনি একটি ভেরিফায়েড ইমেইল অ্যাড্রেস ক্যাপচার করেন। এরপর রয়েছে সোশ্যাল লগইন — Facebook, Google, Apple ID — যা আপনাকে একটি সমৃদ্ধ প্রোফাইল এবং একটি ভেরিফায়েড আইডেন্টিটি দেয়, যদিও আপনি থার্ড-পার্টি OAuth ফ্লো এবং সেই প্ল্যাটফর্মগুলোর ডেটা শেয়ারিং পলিসির ওপর নির্ভরশীল। এবং আরও অত্যাধুনিক প্রান্তে, আপনার কাছে কাস্টম ফিল্ড, লয়্যালটি প্রোগ্রাম ইন্টিগ্রেশন এবং CRM সিনক্রোনাইজেশন সহ ফর্ম-ভিত্তিক রেজিস্ট্রেশন রয়েছে। অথেনটিকেশন পদ্ধতি নির্বাচন আপনার ডেটা কোয়ালিটি, আপনার কনভার্শন রেট এবং আপনার কমপ্লায়েন্স পজিশনের ওপর সরাসরি প্রভাব ফেলে। একটি ক্লিক-থ্রু আপনাকে প্রায় ১০০% কানেকশন রেট দেয় কিন্তু শূন্য ফার্স্ট-পার্টি ডেটা। একটি বিস্তারিত রেজিস্ট্রেশন ফর্ম আপনার কানেকশন রেট ৬০ বা ৭০ শতাংশে নামিয়ে আনতে পারে কিন্তু আপনাকে অ্যাকশনেবল মার্কেটিং ডেটা দেয়। বেশিরভাগ এন্টারপ্রাইজ ডিপ্লয়মেন্টের জন্য সবচেয়ে উপযুক্ত হলো সোশ্যাল লগইন বা একটি সিঙ্গেল মার্কেটিং অপ্ট-ইন চেকবক্স সহ ইমেইল রেজিস্ট্রেশন — উচ্চ কনভার্শন বজায় রাখার জন্য বাধা যথেষ্ট কম, বাণিজ্যিকভাবে কার্যকর হওয়ার জন্য ডেটা কোয়ালিটি যথেষ্ট বেশি। কমপ্লায়েন্সের দিক থেকে, এটি আপসহীন। আপনি যদি যুক্তরাজ্য বা ইইউ-তে কাজ করেন, তবে GDPR প্রযোজ্য। আপনার স্প্ল্যাশ পেজে যেকোনো মার্কেটিং কমিউনিকেশনের জন্য একটি পরিষ্কার, ইতিবাচক সম্মতি মেকানিজম উপস্থাপন করতে হবে। প্রি-টিক করা বক্সগুলো GDPR-এর আর্টিকেল ৭-এর অধীনে বৈধ সম্মতি নয়। আপনার প্রাইভেসি নোটিশ অ্যাক্সেসযোগ্য হতে হবে — ৪০ পৃষ্ঠার PDF-এ লুকানো নয় — এবং আপনাকে অবশ্যই প্রমাণ করতে সক্ষম হতে হবে যে সম্মতি স্বাধীনভাবে, সুনির্দিষ্টভাবে, জ্ঞাতসারে এবং দ্ব্যর্থহীনভাবে দেওয়া হয়েছিল। আপনি যদি কোনো হেলথকেয়ার পরিবেশে থাকেন, তবে আপনাকে এটাও বিবেচনা করতে হবে যে ক্যাপচার করা কোনো ডেটা আর্টিকেল ৯-এর অধীনে স্পেশাল ক্যাটাগরি ডেটা গঠন করতে পারে কিনা। এবং যদি আপনার গেস্ট WiFi নেটওয়ার্ক কোনো পেমেন্ট কার্ড ডেটা বহন করে — এমনকি পরোক্ষভাবেও — PCI DSS স্কোপ ক্রিপ একটি বাস্তব ঝুঁকি যা সঠিক নেটওয়ার্ক সেগমেন্টেশনের মাধ্যমে সমাধান করা প্রয়োজন। [ইমপ্লিমেন্টেশন রেকমেন্ডেশন এবং পিটফলস — আনুমানিক ২ মিনিট] ঠিক আছে, চলুন ডিপ্লয়মেন্ট নিয়ে কথা বলি। আপনি একটি ২০০-রুমের হোটেল, একটি ৫০-ব্রাঞ্চের রিটেইল চেইন, বা একটি ৪০,০০০-সিটের স্টেডিয়াম জুড়ে রোল আউট করুন না কেন, শুরুতে আপনি যে আর্কিটেকচারাল সিদ্ধান্তগুলো নেবেন তা নির্ধারণ করবে স্কেল করার সময় আপনি কতটা সমস্যার সম্মুখীন হবেন। প্রথমত: ক্লাউড-ম্যানেজড বনাম অন-প্রিমিস। মাল্টি-সাইট ডিপ্লয়মেন্টের জন্য, ক্লাউড-ম্যানেজড Captive Portal সলিউশনগুলো প্রায় সবসময়ই সঠিক উত্তর। এগুলো আপনাকে সেন্ট্রালাইজড স্প্ল্যাশ পেজ ম্যানেজমেন্ট, সমস্ত লোকেশন জুড়ে ধারাবাহিক ব্র্যান্ডিং, রিয়েল-টাইম অ্যানালিটিক্স এবং পৃথক অ্যাক্সেস কন্ট্রোলার স্পর্শ না করেই আপডেট পুশ করার ক্ষমতা দেয়। অন-প্রিমিস সলিউশনগুলোর নিজস্ব জায়গা রয়েছে — হাই-সিকিউরিটি পরিবেশ, দুর্বল WAN কানেক্টিভিটি সহ ভেন্যু, বা কঠোর ডেটা রেসিডেন্সি প্রয়োজনীয়তা সহ সংস্থা — কিন্তু অপারেশনাল ওভারহেড উল্লেখযোগ্যভাবে বেশি। উদাহরণস্বরূপ, Purple-এর প্ল্যাটফর্ম একটি ক্লাউড-ম্যানেজড সলিউশন হিসেবে কাজ করে যা ভেন্ডর নির্বিশেষে আপনার বিদ্যমান অ্যাক্সেস পয়েন্ট ইনফ্রাস্ট্রাকচারের সাথে ইন্টিগ্রেট করে, যা মাল্টি-ভেন্ডর পরিবেশে একটি উল্লেখযোগ্য সুবিধা। দ্বিতীয়ত: রিডাইরেক্ট ল্যাটেন্সি সমস্যাকে অবমূল্যায়ন করবেন না। Captive Portal সম্পর্কে সবচেয়ে সাধারণ অভিযোগগুলোর মধ্যে একটি হলো স্প্ল্যাশ পেজ আসতে খুব বেশি সময় নেয়। এটি সাধারণত তিনটি জিনিসের যেকোনো একটির কারণে ঘটে: ধীর DNS রিডাইরেক্ট রেসপন্স টাইম, স্প্ল্যাশ পেজটি নিজেই একটি দুর্বল সার্ভারে হোস্ট করা, অথবা — এবং এটি ক্রমশ সাধারণ হয়ে উঠছে — শুধুমাত্র-HTTPS ব্রাউজিং প্রাথমিক HTTP রিডাইরেক্ট ফায়ার হতে বাধা দেয়। আধুনিক অপারেটিং সিস্টেমগুলো Captive Portal ডিটেকশন মোটামুটি ভালোভাবে পরিচালনা করে, তবে গো-লাইভের আগে আপনার iOS, Android, Windows এবং macOS জুড়ে আপনার ডিপ্লয়মেন্ট পরীক্ষা করা উচিত, কারণ এর আচরণ ভিন্ন হয়। তৃতীয়ত: সেশন ম্যানেজমেন্ট। আগেই সিদ্ধান্ত নিন একটি সেশন কতক্ষণ স্থায়ী হবে, এর মেয়াদ শেষ হলে কী হবে এবং ফিরে আসা ইউজারদের পুনরায় অথেনটিকেট করতে হবে কিনা। হসপিটালিটির জন্য, রুম বুকিংয়ের সাথে যুক্ত একটি ২৪-ঘণ্টার সেশন যুক্তিসঙ্গত। রিটেইল পরিবেশের জন্য, আপনি একটি নতুন প্রমোশনাল মেসেজ পরিবেশন করে এমন একটি রি-অথেনটিকেশন প্রম্পট সহ একটি ছোট সেশন চাইতে পারেন। একটি স্টেডিয়াম বা ইভেন্ট ভেন্যুর জন্য, একটি সিঙ্গেল-ডে সেশন সাধারণত উপযুক্ত। এগুলো শুধু UX সিদ্ধান্ত নয় — এগুলো আপনার RADIUS সার্ভার লোড এবং আপনার অ্যানালিটিক্স ডেটা কোয়ালিটিকে প্রভাবিত করে। এবার আসি ফাঁদগুলোর কথায়। এন্টারপ্রাইজ ডিপ্লয়মেন্টে আমি সবচেয়ে বড় যে ফাঁদটি দেখি তা হলো স্প্ল্যাশ পেজটিকে একটি সেট-অ্যান্ড-ফরগেট অ্যাসেট হিসেবে বিবেচনা করা। আপনার স্প্ল্যাশ পেজ একটি লাইভ মার্কেটিং চ্যানেল। এটি সিজন অনুযায়ী আপডেট করা উচিত, কনভার্শন রেটের জন্য পরীক্ষা করা উচিত এবং কমপ্লায়েন্স পরিবর্তনের জন্য রিভিউ করা উচিত — বিশেষ করে যেহেতু GDPR গাইডেন্স বিবর্তিত হচ্ছে। দ্বিতীয় ফাঁদটি হলো দুর্বল মোবাইল অপ্টিমাইজেশন। ৮০ শতাংশেরও বেশি গেস্ট WiFi কানেকশন স্মার্টফোন থেকে তৈরি হয়। যদি আপনার স্প্ল্যাশ পেজটি সম্পূর্ণ রেসপন্সিভ না হয় এবং 4G কানেকশনে তিন সেকেন্ডের মধ্যে লোড না হয়, তবে আপনি কানেকশন হারাচ্ছেন। তৃতীয় ফাঁদটি হলো পোস্ট-অথেনটিকেশন এক্সপেরিয়েন্সকে অবহেলা করা। ইউজার কানেক্ট হওয়ার পর কী হয়? তারা কি কোনো প্রমোশনাল অফার সহ একটি ব্র্যান্ডেড ওয়েলকাম পেজে ল্যান্ড করে? নাকি তারা যে সাইটে পৌঁছানোর চেষ্টা করছিল সেখানে তাদের ডাম্প করা হয়? সেই পোস্ট-কানেকশন মুহূর্তটি একটি হাই-অ্যাটেনশন টাচপয়েন্ট যা বেশিরভাগ অপারেটর সম্পূর্ণভাবে নষ্ট করে। [র‍্যাপিড-ফায়ার Q&A — আনুমানিক ১ মিনিট] আইটি এবং অপারেশন টিমের কাছ থেকে আমি নিয়মিত শুনি এমন কয়েকটি প্রশ্নের উত্তর দিচ্ছি。 "আমরা কি আমাদের বিদ্যমান অ্যাক্সেস পয়েন্টগুলো ব্যবহার করতে পারি?" — বেশিরভাগ ক্ষেত্রেই, হ্যাঁ। Purple-এর মতো ক্লাউড-ম্যানেজড Captive Portal প্ল্যাটফর্মগুলো স্ট্যান্ডার্ড RADIUS বা API ইন্টিগ্রেশনের মাধ্যমে Cisco Meraki, Aruba, Ruckus, Ubiquiti এবং অন্যান্য বেশিরভাগ এন্টারপ্রাইজ AP ভেন্ডরের সাথে ইন্টিগ্রেট করে। "যে ডিভাইসগুলো Captive Portal ডিটেকশন সাপোর্ট করে না সেগুলোকে আমরা কীভাবে হ্যান্ডেল করব?" — আপনি একটি ওয়াল্ড গার্ডেন কনফিগার করবেন: IP অ্যাড্রেস এবং ডোমেইনের একটি হোয়াইটলিস্ট যা অথেনটিকেশনের আগে অ্যাক্সেসযোগ্য। এটি নিশ্চিত করে যে আপনার স্প্ল্যাশ পেজটি সর্বদা পৌঁছানো সম্ভব। "গেস্টদের জন্য কি আমাদের একটি আলাদা SSID প্রয়োজন?" — হ্যাঁ, সবসময়। গেস্ট ট্রাফিক অবশ্যই আপনার কর্পোরেট নেটওয়ার্ক থেকে আলাদা করতে হবে। ন্যূনতম প্রয়োজনীয়তা হলো VLAN সেগমেন্টেশন; বেস্ট প্র্যাকটিস হলো নিজস্ব ইন্টারনেট ব্রেকআউট সহ একটি সম্পূর্ণ আলাদা ফিজিক্যাল বা লজিক্যাল নেটওয়ার্ক। "WPA3-এর কী হবে?" — WPA3 হলো ওয়্যারলেস সিকিউরিটির বর্তমান স্ট্যান্ডার্ড এবং যেকোনো নতুন ডিপ্লয়মেন্টের জন্য এটি আপনার ডিফল্ট হওয়া উচিত। মনে রাখবেন যে WPA3 Simultaneous Authentication of Equals ব্যবহার করে, যা হ্যান্ডশেক আচরণ পরিবর্তন করে — নিশ্চিত করুন যে আপনার Captive Portal কন্ট্রোলার এটি সাপোর্ট করে। [সামারি এবং নেক্সট স্টেপস — আনুমানিক ১ মিনিট] তাহলে শেষ করা যাক। একটি WiFi স্প্ল্যাশ পেজ হলো ব্র্যান্ডেড, ইন্টারেক্টিভ ওয়েব ইন্টারফেস যা আপনার গেস্ট WiFi নেটওয়ার্কের সামনে থাকে। এটি একটি Captive Portal সিস্টেমের ইউজার-ফেসিং কম্পোনেন্ট, এবং এটি একই সাথে একটি নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল মেকানিজম, একটি ডেটা ক্যাপচার টুল, একটি কমপ্লায়েন্স চেকলিস্ট এবং একটি মার্কেটিং চ্যানেল। মূল সিদ্ধান্তগুলো হলো: অথেনটিকেশন পদ্ধতি, ডেটা ফিল্ড, সম্মতি মেকানিজম, সেশনের মেয়াদ এবং পোস্ট-কানেকশন এক্সপেরিয়েন্স। এগুলো সঠিকভাবে করুন, এবং আপনার গেস্ট WiFi একটি ফার্স্ট-পার্টি ডেটা অ্যাসেটে পরিণত হবে যা পরিমাপযোগ্য মার্কেটিং ROI ড্রাইভ করে। এগুলো ভুল করুন, এবং আপনার কাছে একটি কমপ্লায়েন্স লায়াবিলিটি এবং একটি হতাশাজনক গেস্ট এক্সপেরিয়েন্স থাকবে। আপনি যদি আপনার ডিপ্লয়মেন্ট মূল্যায়ন বা রিডিজাইন করে থাকেন, তবে আমি Purple-এর গেস্ট WiFi প্ল্যাটফর্ম দিয়ে শুরু করার পরামর্শ দেব — এটি একটি সিঙ্গেল ক্লাউড-ম্যানেজড সলিউশনে Captive Portal ইনফ্রাস্ট্রাকচার, স্প্ল্যাশ পেজ বিল্ডার, অ্যানালিটিক্স এবং CRM ইন্টিগ্রেশনগুলো পরিচালনা করে। শো নোটে Purple গেস্ট WiFi প্রোডাক্ট পেজ এবং ক্লাউড বনাম অন-প্রিমিস Captive Portal ডিপ্লয়মেন্টের গাইডের একটি লিংক দেওয়া আছে। শোনার জন্য ধন্যবাদ। আগামী পর্ব পর্যন্ত বিদায়।