Captive Portal রিডাইরেক্টের সমস্যা সমাধান: গেস্ট WiFi সংযোগের ব্যর্থতা দূর করা
যখন গেস্টরা আপনার WiFi এর সাথে সংযুক্ত হন কিন্তু ইন্টারনেট অ্যাক্সেস করতে পারেন না, তখন এর কারণ প্রায় সবসময়ই একটি ভুল কনফিগার করা Captive Portal রিডাইরেক্ট - কোনো হার্ডওয়্যার ত্রুটি নয়। এই নির্দেশিকাটি আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং CTO-দের জন্য একটি গভীর প্রযুক্তিগত রেফারেন্স প্রদান করে যাতে সম্পূর্ণ ব্যর্থতার চেইনটি নির্ণয় এবং সমাধান করা যায়: OS-স্তরের কানেক্টিভিটি প্রোব এবং HSTS সার্টিফিকেট দ্বন্দ্ব থেকে শুরু করে RADIUS অথরাইজেশন গ্যাপ এবং DHCP এক্সহশন পর্যন্ত। এটি প্রতিটি ব্যর্থতার মোডকে একটি সুনির্দিষ্ট সমাধানের সাথে ম্যাপিং করে এবং দেখায় কীভাবে Purple-এর হার্ডওয়্যার-অ্যাগনস্টিক ক্লাউড ওভারলে Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet ডিপ্লয়মেন্ট জুড়ে এই সমস্যাগুলি দূর করে।
Video overview
এই গাইডটি শুনুন
পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
আমাদের মূল সিরিজের অংশ: Captive Portal নির্দেশিকা →
এক্সিকিউটিভ সামারি
এন্টারপ্রাইজ নেটওয়ার্কিংয়ের ক্ষেত্রে সবচেয়ে সাধারণ সাপোর্ট টিকিটগুলির মধ্যে একটি হলো 'guest WiFi connected but no internet' কুয়েরিটি। এর লক্ষণটি প্রত্যেক ভিজিটর দেখতে পান; কিন্তু রিডাইরেক্ট চেইন সম্পর্কে ধারণা না থাকা পর্যন্ত বেশিরভাগ IT টিমের কাছে এর আসল কারণটি অদৃশ্যই থেকে যায়। একটি Captive Portal (যাকে স্প্ল্যাশ পেজ বা হটস্পট গেটওয়েও বলা হয়) ডিভাইসের প্রাথমিক HTTP কানেক্টিভিটি প্রোবকে ইন্টারসেপ্ট বা বাধাগ্রস্ত করে এবং একটি লগইন পেজে HTTP 302 রিডাইরেক্ট ইস্যু করে। যদি সেই চেইনের কোনো ধাপে সমস্যা দেখা দেয় - যেমন ব্লকড প্রোব, HSTS দ্বন্দ্ব, ওয়াল্ড গার্ডেন গ্যাপ, RADIUS ব্যর্থতা, অথবা DHCP এক্সহশশন - তাহলে গেস্ট কেবল একটি সংযুক্ত WiFi আইকন দেখতে পান কিন্তু কোনো ইন্টারনেট পান না। এই গাইডটি আপনাকে প্রতিটি ফেইলিয়ার মোড, এর পেছনের প্রোটোকল মেকানিক্স এবং কনফিগারেশন পরিবর্তনগুলি বুঝতে সাহায্য করবে যা এই সমস্যাগুলির সমাধান করে। Purple ৮০,০০০+ এরও বেশি লাইভ ভেন্যুতে কাজ করে এবং বার্ষিক ৪৪০ মিলিয়ন লগইন প্রসেস করে (Purple ইন্টারনাল ডেটা, ২০২৪), এবং এখানে বর্ণিত প্যাটার্নগুলি আতিথেয়তা, খুচরা বিক্রেতা, পরিবহন এবং পাবলিক সেক্টর ডেপ্লয়মেন্টে আমাদের দেখা সবচেয়ে ঘন ঘন ঘটে যাওয়া মূল কারণগুলিকে রিপ্রেজেন্ট করে।
টেকনিক্যাল ডিপ-ডাইভ
যেভাবে Captive Portal ডিটেকশন আসলে কাজ করে
ইন্টারনেট অ্যাক্সেস দেওয়ার আগে কোনো নেটওয়ার্কের প্রমাণীকরণ বা অথেনটিকেশনের প্রয়োজন আছে কিনা তা সনাক্ত করার জন্য প্রতিটি বড় অপারেটিং সিস্টেমে একটি বিল্ট-ইন মেকানিজম থাকে। এই মেকানিজমগুলি বুঝতে পারা হলো সমস্ত Captive Portal ট্রাবলশুটিংয়ের মূল ভিত্তি।
যখন একটি ডিভাইস কোনো SSID-এর সাথে যুক্ত হয়, তখন OS একটি পূর্বনির্ধারিত URL-এ একটি আনএনক্রিপ্টেড HTTP GET রিকোয়েস্ট পাঠায়। নিচের টেবিলে প্ল্যাটফর্ম অনুযায়ী প্রোব URL গুলি তালিকাভুক্ত করা হয়েছে।
| অপারেটিং সিস্টেম | প্রোব URL | প্রত্যাশিত প্রতিক্রিয়া |
|---|---|---|
| iOS / macOS | http://captive.apple.com/hotspot-detect.html |
নির্দিষ্ট বডি সহ HTTP 200 |
| Android (Google) | http://connectivitycheck.gstatic.com/generate_204 |
HTTP 204 No Content |
| Windows (NCSI) | http://www.msftconnecttest.com/connecttest.txt |
'Microsoft Connect Test' বডি সহ HTTP 200 |
| Chrome (সব প্ল্যাটফর্ম) | http://www.gstatic.com/generate_204 |
HTTP 204 No Content |
| Firefox | http://detectportal.firefox.com/success.txt |
HTTP 200 |
যদি গেটওয়ে এই রিকোয়েস্টগুলির মধ্যে একটিকে ইন্টারসেপ্ট করে এবং Captive Portal URL-এর দিকে নির্দেশকারী একটি HTTP 302 রিডাইরেক্ট রিটার্ন করে, তবে OS বুঝতে পারে যে এটি একটি পোর্টালের অধীনে রয়েছে এবং স্প্ল্যাশ পেজটি প্রদর্শন করার জন্য একটি সিউডো-ব্রাউজার (একটি লাইটওয়েট WebView) ওপেন করে। যদি প্রোবটি সম্পূর্ণরূপে ব্লক হয়ে যায়, তবে OS 'No internet connection' রিপোর্ট করে এবং কখনই পোর্টালটি খোলার চেষ্টা করে না। এটিই হলো 'guest WiFi connected but no internet' লক্ষণের একক সবচেয়ে সাধারণ কারণ।
HSTS সমস্যা
HTTP Strict Transport Security (HSTS) হল RFC 6797-এ সংজ্ঞায়িত একটি ওয়েব সিকিউরিটি পলিসি। এটি ব্রাউজারগুলোকে একটি ডোমেনে সমস্ত প্লেইন HTTP কানেকশন প্রত্যাখ্যান করতে এবং হুবহু মেলে না এমন যেকোনো সার্টিফিকেট বাতিল করার নির্দেশ দেয়। google.com, facebook.com এবং বেশিরভাগ ব্যাংকিং সাইটসহ প্রধান ডোমেনগুলো Chrome, Firefox, Safari এবং Edge ব্রাউজারে বিল্ট-ইন থাকা HSTS প্রিলোড তালিকায় অন্তর্ভুক্ত রয়েছে।
যখন একজন গেস্ট ব্রাউজার ওপেন করে এবং google.com টাইপ করে, তখন ব্রাউজারটি ডিভাইস থেকে রিকোয়েস্টটি বের হওয়ার আগেই সেটিকে HTTPS-এ আপগ্রেড করে। গেটওয়ে কোনো HTTPS রিকোয়েস্ট ইন্টারসেপ্ট করতে এবং এটিকে পরিচ্ছন্নভাবে রিডাইরেক্ট করতে পারে না - এর জন্য google.com-এর একটি সার্টিফিকেট প্রদর্শন করার প্রয়োজন হবে, যা এটির কাছে নেই। ব্রাউজারটি সার্টিফিকেটের অমিল সনাক্ত করে এবং একটি কঠিন সিকিউরিটি ওয়ার্নিং প্রদর্শন করে। গেস্ট লগইন পেজে যেতে পারেন না।
সঠিক আর্কিটেকচারটি সম্পূর্ণভাবে উপরে বর্ণিত OS-লেভেলের HTTP প্রোবের ওপর নির্ভর করে। এই প্রোবগুলো বিশেষভাবে নন-HSTS URL-এ প্লেইন HTTP ব্যবহার করে যাতে গেটওয়েগুলো সার্টিফিকেটের কোনো দ্বন্দ্ব ছাড়াই সেগুলোকে ইন্টারসেপ্ট এবং রিডাইরেক্ট করতে পারে। আপনার গেটওয়েকে অবশ্যই এই HTTP প্রোবগুলো ইন্টারসেপ্ট করতে হবে এবং 302 রিডাইরেক্ট ইস্যু করতে হবে। Captive Portal-এর উদ্দেশ্যে HTTPS ট্রাফিক ইন্টারসেপ্ট করার চেষ্টা করবেন না।
walled garden
walled garden হলো ডোমেন এবং IP অ্যাড্রেসের এমন একটি সেট যা কোনো ডিভাইস অথেন্টিকেট হওয়ার আগেই অ্যাক্সেস করতে পারে। walled garden যদি খুব সংকীর্ণ হয়, তবে স্প্ল্যাশ পেজ লোড হতে পারে কিন্তু অথেন্টিকেশন ব্যর্থ হবে। সাধারণ গ্যাপগুলোর মধ্যে রয়েছে:
- আইডেন্টিটি প্রোভাইডার ডোমেন: আপনি যদি সোশ্যাল বা SSO লগইনের জন্য Microsoft Entra ID, Okta বা Google Workspace ব্যবহার করেন, তবে তাদের অথেন্টিকেশন এন্ডপয়েন্টগুলো অবশ্যই walled garden-এ থাকতে হবে।
- CDN এবং অ্যাসেট ডোমেন: আপনার স্প্ল্যাশ পেজ একটি কনটেন্ট ডেলিভারি নেটওয়ার্ক থেকে CSS, JavaScript বা ফন্ট লোড করতে পারে। যদি সেই CDN ডোমেনগুলো ব্লক করা থাকে, তবে পেজটি ভাঙা দেখাবে।
- পেমেন্ট প্রসেসর ডোমেন: আপনি যদি Stripe বা অন্য কোনো প্রসেসরের মাধ্যমে অ্যাক্সেসের জন্য চার্জ করেন, তবে তাদের JavaScript SDK ডোমেনগুলো অবশ্যই আগে থেকে অথেন্টিকেট করা থাকতে হবে।
- Purple প্ল্যাটফর্ম ডোমেন: Purple-এর ক্লাউড ওভারলে-এর জন্য গেটওয়েকে অবশ্যই Purple-এর RADIUS সার্ভার এবং পোর্টাল এন্ডপয়েন্টগুলোতে পৌঁছাতে হবে। এগুলো প্রতিটি সমর্থিত প্ল্যাটফর্মের জন্য Purple-এর হার্ডওয়্যার ইন্টিগ্রেশন গাইডে ডকুমেন্ট করা হয়েছে।
RADIUS এবং অথরাইজেশন গ্যাপ
RADIUS (Remote Authentication Dial-In User Service) হলো এমন একটি প্রোটোকল যা আপনার লোকাল গেটওয়েকে অথেন্টিকেশন প্ল্যাটফর্মের সাথে সংযুক্ত করে। যখন একজন গেস্ট লগইন ফর্মটি পূরণ করেন, তখন Captive Portal ক্রেডেন্সিয়ালগুলো RADIUS সার্ভারে পাঠায়। RADIUS সার্ভার একটি Access-Accept বা Access-Reject মেসেজ ফেরত পাঠায়। গেটওয়ে সেই মেসেজের ওপর ভিত্তি করে ইন্টারনেট অ্যাক্সেস প্রদানকারী ফায়ারওয়াল রুলটি ওপেন বা ক্লোজড রাখে।
অথরাইজেশন গ্যাপ - যেখানে একজন গেস্ট স্প্ল্যাশ পেজে সফলভাবে লগইন করেন কিন্তু তবুও কোনো ইন্টারনেট পান না - এর মানে প্রায় সবসময়ই গেটওয়ে Access-Accept মেসেজটি পায়নি বা প্রসেস করেনি। সাধারণ কারণগুলোর মধ্যে রয়েছে অমিল থাকা শেয়ার্ড সিক্রেট, একটি লোকাল ফায়ারওয়াল দ্বারা UDP পোর্ট 1812 এবং 1813 ব্লক থাকা, অথবা গেটওয়েতে RADIUS সার্ভারের IP অ্যাড্রেস ভুলভাবে কনফিগার করা থাকা।
হাই-ডেনসিটি পরিবেশে DHCP নিঃশেষ হওয়া
স্টেডিয়াম, কনফারেন্স সেন্টার এবং ট্রান্সপোর্ট হাবগুলিতে, DHCP নিঃশেষ হয়ে যাওয়া কানেকশন ব্যর্থতার একটি ঘন ঘন কারণ যা একটি captive portal সমস্যার মতোই দেখায়। যদি DHCP পুল পূর্ণ থাকে, তাহলে একটি নতুন ডিভাইস অ্যাক্সেস পয়েন্টের সাথে যুক্ত হয় কিন্তু কখনই একটি IP অ্যাড্রেস পায় না। IP অ্যাড্রেস ছাড়া, ডিভাইসটি HTTP প্রোব পাঠাতে পারে না এবং কখনই captive portal-এ পৌঁছায় না। ডিভাইসটি SSID-এর সাথে সংযুক্ত হিসাবে দেখায় কিন্তু কোনো ইন্টারনেট থাকে না।
ম্যানচেস্টার এয়ারপোর্টস গ্রুপ (MAG)-এর মতো ভেন্যুগুলির জন্য, যেখানে যাত্রীদের ভিড় তীব্রভাবে বৃদ্ধি পায়, সাবনেটগুলির আকার সর্বাধিক এককালীন ডিভাইস সংখ্যার জন্য নির্ধারণ করা উচিত, গড় সংখ্যার জন্য নয়। সংক্ষিপ্ত DHCP লিজ টাইম (ক্ষণস্থায়ী ভিজিটর নেটওয়ার্কের জন্য ১৫-৩০ মিনিট) প্রস্থান করা ডিভাইসগুলি থেকে দ্রুত অ্যাড্রেসগুলি পুনরুদ্ধার করে।
বাস্তবায়ন নির্দেশিকা
নিম্নলিখিত পদক্ষেপগুলি যেকোনো হার্ডওয়্যার প্ল্যাটফর্মের ক্ষেত্রে প্রযোজ্য - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme বা Fortinet - যখন Purple-এর ক্লাউড ওভারলে-এর সাথে সমন্বয় করা হয়।
পদক্ষেপ ১: বাহ্যিক captive portal-এর জন্য SSID কনফিগার করুন। আপনার হার্ডওয়্যার কন্ট্রোলারে, অ-প্রমাণিত ক্লায়েন্টদের Purple-এর বাহ্যিক পোর্টাল URL-এ রিডাইরেক্ট করতে গেস্ট SSID সেট করুন। কন্ট্রোলারের নিজস্ব যেকোনো লোকাল স্প্ল্যাশ পেজ নিষ্ক্রিয় করুন।
পদক্ষেপ ২: walled garden নির্ধারণ করুন। ন্যূনতম নিম্নলিখিত ডোমেনগুলি যোগ করুন: Purple-এর পোর্টাল এবং RADIUS এন্ডপয়েন্ট (আপনার হার্ডওয়্যার ইন্টিগ্রেশন গাইড দেখুন), উপরে তালিকাভুক্ত OS ডিটেকশন প্রোব URL, আপনার আইডেন্টিটি প্রোভাইডার ডোমেন (Microsoft Entra ID, Okta, বা Google Workspace) এবং আপনার স্প্ল্যাশ পেজ অ্যাসেট ব্যবহার করে এমন যেকোনো CDN ডোমেন।
পদক্ষেপ ৩: RADIUS কনফিগার করুন। Purple-এর RADIUS সার্ভার IP অ্যাড্রেস, আপনার Purple ড্যাশবোর্ড থেকে শেয়ার্ড সিক্রেট লিখুন এবং অথেনটিকেশন পোর্ট ১৮১২ এবং অ্যাকাউন্টিং পোর্ট ১৮১৩-এ সেট করুন। যাচাই করুন যে আপনার লোকাল ফায়ারওয়াল এই পোর্টগুলিতে আউটবাউন্ড UDP-এর অনুমতি দেয়।
পদক্ষেপ ৪: সেশন প্যারামিটার সেট করুন। হসপিটালিটি এবং রিটেইলের জন্য, সেশনের মেয়াদ ২৪ ঘণ্টা সেট করুন এবং MAC অ্যাড্রেস ক্যাশিং সক্ষম করুন। এটি অতিথিদের একক ভিজিটের সময় বারবার প্রমাণীকরণ করতে বাধ্য হওয়া থেকে রক্ষা করে। উচ্চ-নিরাপত্তা সম্পন্ন পরিবেশের জন্য, পুনরায় প্রমাণীকরণ সহ ছোট সেশন উপযুক্ত।
পদক্ষেপ ৫: আপনার DHCP স্কোপের আকার নির্ধারণ করুন। পিক ক্যাপাসিটিতে আপনার ভেন্যুর জন্য সর্বাধিক এককালীন ডিভাইস সংখ্যা গণনা করুন। একটি ৫০০-সিটের রেস্তোরাঁয় ব্যস্ত পরিষেবার সময় ৮০০টি ডিভাইস দেখা যেতে পারে। ৩০ মিনিটের লিজ টাইম সহ DHCP পুলের আকার ১,০০০টি অ্যাড্রেসে নির্ধারণ করুন।
পদক্ষেপ ৬: অপারেটিং সিস্টেম জুড়ে পরীক্ষা করুন। কনফিগারেশনের পরে, iOS, Android এবং Windows ডিভাইসে সম্পূর্ণ ফ্লো পরীক্ষা করুন। প্রতিটি একটি ভিন্ন প্রোব URL এবং WebView ইমপ্লিমেন্টেশন ব্যবহার করে। অন্যান্য প্ল্যাটফর্ম কাজ করার সময় একটি প্ল্যাটফর্মে ব্যর্থতা প্রায়শই একটি walled garden ফাঁকফোকরের কারণে ঘটে।
আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?
আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।
সেরা অনুশীলন
নিম্নলিখিত সুপারিশগুলি Purple-এর ৮০,০০০টিরও বেশি ভেন্যু ডেপ্লয়মেন্ট জুড়ে মানদণ্ড এবং প্যাটার্নগুলিকে প্রতিফলিত করে।
আলাদা অতিথি এবং স্টাফ নেটওয়ার্ক। কমপক্ষে তিনটি SSIDs চালান: Guest WiFi, Staff WiFi এবং একটি IoT নেটওয়ার্ক। অতিথিদের ট্র্যাফিক অবশ্যই অভ্যন্তরীণ সিস্টেম থেকে বিচ্ছিন্ন থাকতে হবে। আর্কিটেকচারাল বিস্তারিত জানতে আমাদের নির্দেশিকা Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi দেখুন।
একটি ডেডিকেটেড গেস্ট VLAN ব্যবহার করুন। ল্যাটারাল মুভমেন্ট প্রতিরোধ করতে এবং ফায়ারওয়াল পলিসি সহজ করতে গেস্ট ট্র্যাফিককে নিজস্ব VLAN-এ বিভক্ত করুন। যদি কোনও পেমেন্ট কার্ড ডেটা নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয় তবে এটি একটি PCI-DSS প্রয়োজনীয়তা।
সচেতন-পছন্দ ভিত্তিক অপ্ট-ইন প্রয়োগ করুন। GDPR-এর প্রয়োজনীয়তা হল যে Captive Portal-এ ডেটা সংগ্রহ অবশ্যই তথ্যযুক্ত, ইতিবাচক সম্মতির উপর ভিত্তি করে হতে হবে। Purple-এর সচেতন-পছন্দ ভিত্তিক অপ্ট-ইনগুলি প্রতিটি উদ্দেশ্যের জন্য আলাদা টিক বক্স সহ ডেটা সংগ্রহের বিকল্পগুলি স্পষ্টভাবে উপস্থাপন করে। UK বা EU-তে কাজ করা ভেন্যুগুলির জন্য এটি ঐচ্ছিক নয়।
সক্রিয়ভাবে পোর্টাল স্বাস্থ্য নিরীক্ষণ করুন। Purple-এর WiFi Analytics প্ল্যাটফর্ম লগইন সাফল্যের হার, সেশন সংখ্যা এবং প্রমাণীকরণ ব্যর্থতার রিয়েল-টাইম দৃশ্যমানতা প্রদান করে। সফল লগইনে আকস্মিক ড্রপ হল অতিথিরা অভিযোগ করা শুরু করার আগেই একটি RADIUS বা ওয়াল্ড গার্ডেন সমস্যার প্রাথমিক সতর্কতা।
সামঞ্জস্যপূর্ণ ব্র্যান্ডিং প্রয়োগ করুন। স্প্ল্যাশ পেজ হল আপনার নেটওয়ার্কের সাথে একজন অতিথির প্রথম ব্র্যান্ডেড মিথস্ক্রিয়া। একটি সুনিয়মিত পোর্টাল অপ্ট-ইন রেট বাড়ায় এবং WiFi অভিজ্ঞতার প্রত্যাশা তৈরি করে। ডিজাইনের নির্দেশনার জন্য How to make a great first impression with your guest WiFi দেখুন।
-
ট্রাবলশুটিং এবং ঝুঁকি হ্রাস
যখন একটি Captive Portal সমস্যা রিপোর্ট করা হয়, তখন কোনো কনফিগারেশন পরিবর্তন করার আগে এই ডায়াগনস্টিক সিকোয়েন্সটি অনুসরণ করুন।
ব্যর্থতার পয়েন্টটি চিহ্নিত করুন। অতিথিকে জিজ্ঞাসা করুন তারা কোন OS এবং ব্রাউজার ব্যবহার করছেন। একই OS-এ নিজে একই ফ্লো পরীক্ষা করুন। সমস্যাটি যদি OS-নির্দিষ্ট হয়, তবে কারণটি নিশ্চিতভাবেই সেই OS-এর প্রোব URL-এর জন্য একটি অনুপস্থিত ওয়াল্ড গার্ডেন এন্ট্রি।
DNS রেজোলিউশন পরীক্ষা করুন। গেস্ট VLAN-এর একটি ডিভাইস থেকে, Captive Portal হোস্টনেম রেজোলিউশন করার চেষ্টা করুন। যদি DNS রেজোলিউশন ব্যর্থ হয়, তবে রিডাইরেক্ট সঠিকভাবে করা হলেও ডিভাইসটি স্প্ল্যাশ পেজে পৌঁছাতে পারবে না। যাচাই করুন যে আপনার DHCP সার্ভার নির্ভরযোগ্য DNS অ্যাড্রেস বিতরণ করছে এবং গেটওয়ে প্রাক-প্রমাণীকরণ অবস্থায় DNS কোয়েরি করার অনুমতি দিচ্ছে।
রিডাইরেক্ট ক্যাপচার করুন। HTTP বিনিময় পর্যবেক্ষণ করতে ব্রাউজার ডেভেলপার টুলস (F12) বা প্যাকেট ক্যাপচার ব্যবহার করুন। আপনার OS প্রোব রিকোয়েস্ট এবং তারপরে পোর্টাল URL ধারণকারী একটি HTTP 302 রেসপন্স দেখা উচিত। আপনি যদি প্রোব রিকোয়েস্ট দেখতে পান কিন্তু কোনো 302 রেসপন্স না পান, তবে গেটওয়েটি সঠিকভাবে ইন্টারসেপ্ট করছে না। আপনি যদি মোটেও কোনো প্রোব রিকোয়েস্ট না দেখতে পান, তবে OS ইতিমধ্যেই নির্ধারণ করেছে যে এটির ইন্টারনেট অ্যাক্সেস আছে (সম্ভবত একটি ক্যাশেড অবস্থা থেকে) এবং প্রোবটি পাঠাচ্ছে না।
RADIUS যোগাযোগ যাচাই করুন। গেটওয়েতে, RADIUS অ্যাকাউন্ট সংক্রান্ত লগগুলো পরীক্ষা করুন। একটি সফল প্রমাণীকরণ একটি Accounting-Start রেকর্ড তৈরি করে। কোনো অতিথি লগ ইন করার পরে যদি আপনি কোনো অ্যাকাউন্টিং রেকর্ড না দেখতে পান, তবে RADIUS যোগাযোগটি বিচ্ছিন্ন রয়েছে। শেয়ার্ড সিক্রেট, সার্ভার IP এবং ফায়ারওয়াল নিয়মগুলো পরীক্ষা করুন।
DHCP লিজের ব্যবহার পরীক্ষা করুন। DHCP সার্ভারে, পুলের আকারের বিপরীতে বর্তমান লিজের সংখ্যা পর্যালোচনা করুন। ব্যবহার যদি ৯০% ছাড়িয়ে যায়, তবে আপনার উপলব্ধ সীমা শেষ হওয়ার কাছাকাছি রয়েছে। অবিলম্বে পুলটি সম্প্রসারণ করুন বা লিজের সময় হ্রাস করুন।
নিচের সারণীটি সবচেয়ে সাধারণ লক্ষণগুলোর সাথে তাদের মূল কারণ এবং প্রাসঙ্গিক সমাধানগুলো ম্যাপিং করে দেখায়।
| লক্ষণ | সবচেয়ে সম্ভাব্য মূল কারণ | সমাধান |
|---|---|---|
| কোনো ডিভাইসেই পোর্টাল দেখা যাচ্ছে না | গেটওয়ে ACL দ্বারা OS প্রোভ ব্লক করা হয়েছে | প্রি-অথরাইজেশন অনুমতি তালিকায় প্রোভ URL-গুলো যোগ করুন |
| iOS-এ পোর্টাল দেখা যাচ্ছে, কিন্তু Android-এ নয় | ওয়াল্ড গার্ডেনে Android প্রোভ URL অনুপস্থিত | ওয়াল্ড গার্ডেনে connectivitycheck.gstatic.com যোগ করুন |
| পোর্টাল লোড হওয়ার সময় HTTPS সার্টিফিকেট ত্রুটি | গেটওয়ে HTTP-এর পরিবর্তে HTTPS ইন্টারসেপ্ট করছে | শুধুমাত্র HTTP প্রোভ ইন্টারসেপশনের ওপর নির্ভর করুন |
| পোর্টাল লোড হচ্ছে, কিন্তু লগইন করার পরে ইন্টারনেট নেই | গেটওয়ে দ্বারা RADIUS Access-Accept প্রাপ্ত হয়নি | শেয়ার্ড সিক্রেট, পোর্ট 1812/1813, RADIUS সার্ভার IP যাচাই করুন |
| সোশ্যাল লগইন বোতামটি নীরবে ব্যর্থ হচ্ছে | পরিচয় প্রদানকারী ডোমেনটি ওয়াল্ড গার্ডেনে নেই | Microsoft Entra ID / Google Workspace এন্ডপয়েন্টগুলো যোগ করুন |
| অতিথিদের প্রতিবার পরিদর্শনের সময় পুনরায় প্রমাণীকরণ করতে হচ্ছে | সেশনের সময়কাল খুব সংক্ষিপ্ত বা MAC ক্যাশিং নিষ্ক্রিয় রয়েছে | সেশন ২৪ ঘণ্টা নির্ধারণ করুন, MAC ঠিকানা ক্যাশিং সক্রিয় করুন |
| ব্যস্ততম সময়ে মাঝে মাঝে সংযোগ ব্যর্থ হচ্ছে | DHCP পুল নিঃশেষ হয়ে গেছে | সাবনেট সম্প্রসারণ করুন, লিজের সময় হ্রাস করুন |
ROI এবং ব্যবসায়িক প্রভাব
ক্যাপটিভ পোর্টালের প্রতিটি ব্যর্থতা হলো একটি ডেটা ক্যাপচার করার সুযোগ হাতছাড়া হওয়া। Purple-এর Guest WiFi প্ল্যাটফর্ম প্রতিটি সফল প্রমাণীকরণকে ফার্স্ট-পার্টি ডেটা রেকর্ডে রূপান্তর করে - নাম, ইমেল, জনসংখ্যা সংক্রান্ত ডেটা এবং পরিদর্শনের ফ্রিকোয়েন্সি - যা সরাসরি মার্কেটিং অটোমেশন এবং লয়্যালটি প্রোগ্রামগুলোতে যুক্ত হয়।
Premier Inn বা Whitbread-এর মতো একটি hospitality অপারেটরের জন্য, একটি ৭০০-প্রপার্টি এস্টেট জুড়ে পোর্টাল প্রমাণীকরণের সাফল্যের হারে ১০% উন্নতি সরাসরি প্রতি মাসে হাজার হাজার অতিরিক্ত অপ্ট-ইন রেকর্ডে পরিণত হয়। সেই রেকর্ডগুলো কেনা তালিকার চেয়ে পরিমাপযোগ্যভাবে উচ্চতর ওপেন রেট সহ ব্যক্তিগতকৃত ইমেল ক্যাম্পেইনগুলোকে চালিত করে।
retail অপারেটরদের জন্য, ক্যাপটিভ পোর্টাল হলো ক্রেতাদের থাকার সময়, বারবার পরিদর্শনের ফ্রিকোয়েন্সি এবং বিভিন্ন লোকেশন জুড়ে আচরণ বোঝার প্রবেশদ্বার। Purple তার ভেন্যু নেটওয়ার্ক জুড়ে ২৯ বিলিয়ন ডেটা পয়েন্ট (Purple অভ্যন্তরীণ ডেটা) সংগ্রহ করেছে। সেই ডেটা ততটাই কার্যকর যতটা কার্যকর প্রমাণীকরণের হার যা এটি তৈরি করে।
Manchester Airports Group-এর মতো transport হাবের জন্য, নির্ভরযোগ্য গেস্ট WiFi হলো একটি যাত্রী সন্তুষ্টির পরিমাপক যা বোর্ড স্তরে ট্র্যাক করা হয়। ব্যস্ততম প্রস্থানকালীন সময়ে যে পোর্টালটি মাঝে মাঝে ব্যর্থ হয় তা অভিযোগের জন্ম দেয় এবং ভেন্যুর নেট প্রোমোটার স্কোরকে ক্ষতিগ্রস্ত করে।healthcare পরিবেশের জন্য, নির্ভরযোগ্য অতিথি WiFi ক্লিনিক্যাল স্টাফদের উপর চাপ কমায় যারা অন্যথায় সংযোগের অভিযোগগুলি সামলাতেন এবং রোগীর অভিজ্ঞতার পরিমাপকে উন্নত করতে সহায়তা করে।
Purple-এর ৯৯.৯৯৯% আপটাইম SLA নিশ্চিত করে যে ক্লাউড ওভারলে নিজে ব্যর্থতার কারণ নয়। যখন পোর্টাল সমস্যা ঘটে, তখন এর কারণ প্রায় সবসময়ই স্থানীয় কনফিগারেশন হয় - যা সমাধান করার জন্য এই নির্দেশিকা আপনাকে কোনও সাপোর্ট টিকিট তৈরি না করেই প্রস্তুত করে।
সূত্র
[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, November 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409
[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910
[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, February 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview
[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, February 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues
[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0
মূল সংজ্ঞাসমূহ
Captive portal
পূর্ণ ইন্টারনেট অ্যাক্সেস মঞ্জুর করার আগে একটি নেটওয়ার্কে যুক্ত হওয়া ডিভাইসের সামনে উপস্থাপিত একটি ওয়েব পেজ। গেটওয়ে ডিভাইসের প্রাথমিক HTTP কানেক্টিভিটি প্রোবকে আটকে দেয় এবং এটিকে পোর্টাল URL-এ রিডাইরেক্ট করে।
হোটেল লবি থেকে শুরু করে স্টেডিয়াম কনকোর্স পর্যন্ত প্রতিটি গেস্ট WiFi লগইন পেজের পিছনের প্রক্রিয়া। RFC ৮৯১০-এ সংজ্ঞায়িত।
Walled garden
ডোমেন এবং IP ঠিকানার সেট যা একটি ডিভাইস captive portal প্রমাণীকরণ সম্পন্ন করার আগে অ্যাক্সেস করতে পারে। walled garden গন্তব্যে ট্রাফিক প্রমাণীকরণের প্রয়োজনীয়তা এড়িয়ে চলে।
এর মধ্যে অবশ্যই OS প্রোব URL, আইডেন্টিটি প্রোভাইডার এন্ডপয়েন্ট, CDN ডোমেন এবং পেমেন্ট প্রসেসর ডোমেন অন্তর্ভুক্ত থাকতে হবে। একটি ভুল কনফিগার করা walled garden হলো captive portal ব্যর্থতার দ্বিতীয় সর্বাধিক সাধারণ কারণ।
NCSI (Network Connectivity Status Indicator)
একটি Windows ফিচার যা `msftconnecttest.com` প্রোব করে নির্ধারণ করে যে ডিভাইসটির ইন্টারনেট অ্যাক্সেস আছে নাকি এটি কোনো captive portal-এর অধীনে রয়েছে। Microsoft-এর নেটওয়ার্কিং ডকুমেন্টেশনে এটি সংজ্ঞায়িত করা হয়েছে।
যদি গেটওয়ে এই প্রোবটি ব্লক করে, তাহলে Windows 'No internet access' রিপোর্ট করে এবং কখনোই captive portal WebView সক্রিয় করে না। এর সমাধান হলো প্রি-অথেনটিকেশন অ্যালাউ লিস্টে NCSI URL যোগ করা।
HSTS (HTTP Strict Transport Security)
RFC 6797-এ সংজ্ঞায়িত একটি ওয়েব সিকিউরিটি পলিসি যা ব্রাউজারগুলোকে প্লেইন HTTP সংযোগ প্রত্যাখ্যান করতে এবং ডোমেনের সাথে হুবহু মেলেনি এমন যেকোনো সার্টিফিকেট প্রত্যাখ্যান করতে নির্দেশ দেয়।
এটি captive portal রিডাইরেকশনের জন্য গেটওয়েকে HTTPS অনুরোধ আটকে দেওয়া থেকে বিরত রাখে। google.com সহ প্রধান ডোমেনগুলো সব প্রধান ব্রাউজারে HSTS প্রিলোড তালিকায় রয়েছে।
HTTP 302 redirect
একটি স্ট্যান্ডার্ড HTTP রেসপন্স কোড যা নির্দেশ করে যে অনুরোধ করা রিসোর্সটি সাময়িকভাবে একটি ভিন্ন URI-তে অবস্থিত, যা Location হেডার-এ প্রদান করা হয়।
গেটওয়েগুলো ডিভাইসের কানেক্টিভিটি প্রোবকে captive portal লগইন পেজে ডাইভার্ট করার জন্য এই মেকানিজম ব্যবহার করে। কিছু গেটওয়ে এর পরিবর্তে HTTP 303 বা একটি রিডাইরেক্ট বডি সহ HTTP 200 ব্যবহার করে।
RADIUS (Remote Authentication Dial-In User Service)
একটি নেটওয়ার্কিং প্রোটোকল যা সেন্ট্রালাইজড প্রমাণীকরণ, অনুমোদন এবং অ্যাকাউন্টিং (AAA) ব্যবস্থাপনা প্রদান করে, যা UDP-এর মাধ্যমে পোর্ট 1812 (প্রমাণীকরণ) এবং 1813 (অ্যাকাউন্টিং)-এ কাজ করে।
Purple-এর ক্লাউড প্ল্যাটফর্ম RADIUS সার্ভার হিসেবে কাজ করে। স্থানীয় গেটওয়ে (Meraki, Aruba, ইত্যাদি) Purple-এর RADIUS সার্ভারগুলোতে প্রমাণীকরণের অনুরোধ পাঠায় এবং Access-Accept বা Access-Reject রেসপন্সের ভিত্তিতে কাজ করে।
MAC address caching
ফিরে আসা ডিভাইসগুলোকে সনাক্ত করতে এবং পুনরায় প্রমাণীকরণের প্রয়োজন ছাড়াই সেশন স্টেট বজায় রাখতে একটি ডিভাইসের অনন্য হার্ডওয়্যার আইডেন্টিফায়ার সংরক্ষণ করার প্রক্রিয়া।
সেশন উইন্ডোর মধ্যে সংক্ষিপ্ত সংযোগ বিচ্ছিন্নতা এবং পুনরাবৃত্তি ভিজিটের ক্ষেত্রে সেশন পারসিস্টেন্স সক্ষম করে। হসপিটালিটি পরিবেশের জন্য অপরিহার্য যেখানে অতিথিরা বিভিন্ন এলাকার মধ্যে চলাফেরা করেন।
Identity-Based Networks
Purple-এর আর্কিটেকচার মডেল যেখানে শুধুমাত্র ডিভাইসের IP বা MAC ঠিকানার পরিবর্তে ব্যবহারকারীর প্রমাণিত পরিচয়ের ভিত্তিতে অ্যাক্সেস পলিসি, VLAN অ্যাসাইনমেন্ট এবং অ্যানালিটিক্স প্রয়োগ করা হয়।
Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet হার্ডওয়্যার জুড়ে বিস্তারিত অ্যাক্সেস কন্ট্রোল, ব্যক্তিগতকৃত অভিজ্ঞতা এবং ব্যক্তিগত ব্যবহারকারীদের জন্য নেটওয়ার্ক আচরণের সঠিক অ্যাট্রিবিউশন সক্ষম করে।
DHCP exhaustion
এমন একটি অবস্থা যেখানে একটি DHCP পুলের সমস্ত উপলব্ধ IP ঠিকানা বরাদ্দ করা হয়ে গেছে, যা নতুন ডিভাইসগুলোকে একটি ঠিকানা পেতে এবং ফলস্বরূপ captive portal-এ পৌঁছাতে বাধা দেয়।
পিক পিরিয়ডে উচ্চ ঘনত্বের ভেন্যুগুলোতে এটি সাধারণ। এটি একটি captive portal ব্যর্থতার মতোই প্রকাশ পায় - ডিভাইস দেখায় যে এটি SSID-এর সাথে সংযুক্ত কিন্তু কোনো ইন্টারনেট নেই। সার্ভারে DHCP লিজ ব্যবহারের হার চেক করে এটি নির্ণয় করা হয়।
সমাধানকৃত উদাহরণসমূহ
HPE Aruba অ্যাক্সেস পয়েন্ট ব্যবহারকারী একটি ২০০-রুমের হোটেল রিপোর্ট করেছে যে Android ডিভাইসের গেস্টরা Captive Portal অ্যাক্সেস করতে পারছেন না, যেখানে iOS ব্যবহারকারীরা কোনো সমস্যা ছাড়াই সংযোগ করছেন। আইটি টিম নিশ্চিত করেছে যে ম্যানেজমেন্ট VLAN থেকে পোর্টাল URL টি অ্যাক্সেসযোগ্য।
আইটি টিমের উচিত HPE Aruba কন্ট্রোলারে প্রি-অথেন্টিকেশন ওয়াল্ড গার্ডেন পরীক্ষা করা। iOS ডিভাইসগুলি captive.apple.com প্রোব করে, যা সম্ভবত ইতিমধ্যেই হোয়াইটলিস্ট করা আছে। Android ডিভাইসগুলি connectivitycheck.gstatic.com এবং clients3.google.com/generate_204 প্রোব করে। এই Google ডোমেনগুলি প্রায় নিশ্চিতভাবেই ওয়াল্ড গার্ডেনে অনুপস্থিত। এগুলিকে প্রি-অথেন্টিকেশন অ্যালাউ লিস্টে যুক্ত করলে সমস্যার সমাধান হবে। টিমের উচিত একটি সেকেন্ডারি Android প্রোব URL হিসেবে connectivitycheck.android.com যুক্ত করা। ওয়াল্ড গার্ডেন আপডেট করার পরে, প্রভাবিত SSID গুলি পুনরায় চালু করুন এবং সমাধানটি নিশ্চিত করতে একটি ফ্যাক্টরি-রিসেট করা Android ডিভাইসে পরীক্ষা করুন, কারণ পূর্বে সংযুক্ত ডিভাইসে ক্যাশ করা নেটওয়ার্ক স্টেট ফলাফলটিকে আড়াল করতে পারে।
১৫০টি Cisco Meraki MX অ্যাপ্লায়েন্স সহ একটি রিটেইল চেইন রিপোর্ট করেছে যে গেস্টরা Purple স্প্ল্যাশ পেজে অথেন্টিকেট করছেন - Purple ড্যাশবোর্ড সফল লগইন দেখাচ্ছে - কিন্তু ফর্মটি পূরণ করার পরেও গেস্টদের কোনো ইন্টারনেট অ্যাক্সেস নেই। এই সমস্যাটি একই সাথে সমস্ত লোকেশনকে প্রভাবিত করছে।
যেহেতু Purple ক্লাউড প্ল্যাটফর্ম সফল লগইন দেখাচ্ছে, তাই অথেন্টিকেশন ধাপটি নিজেই কাজ করছে। ব্যর্থতাটি অথরাইজেশন ধাপে রয়েছে - Meraki অ্যাপ্লায়েন্সটি Purple-এর RADIUS সার্ভার থেকে RADIUS Access-Accept মেসেজ পাচ্ছে না বা সেই অনুযায়ী কাজ করছে না। টিমের পর্যায়ক্রমে তিনটি জিনিস পরীক্ষা করা উচিত: প্রথমত, Meraki ড্যাশবোর্ডে RADIUS শেয়ার্ড সিক্রেটটি Purple পোর্টালে থাকা সিক্রেটের সাথে হুবহু মিলছে কিনা তা যাচাই করুন (একটি মাত্র অক্ষরের পার্থক্য নীরব ব্যর্থতার কারণ হয়); দ্বিতীয়ত, Meraki অ্যাপ্লায়েন্স থেকে Purple-এর RADIUS সার্ভার IP অ্যাড্রেসগুলিতে ১৮১২ এবং ১৮১৩ পোর্টে আউটবাউন্ড UDP ট্রাফিক অনুমোদিত কিনা তা নিশ্চিত করুন; তৃতীয়ত, সাম্প্রতিক কোনো নেটওয়ার্ক পরিবর্তনের ফলে এমন কোনো ফায়ারওয়াল রুল বা NAT পলিসি যুক্ত হয়েছে কিনা যা এই ট্রাফিককে ব্লক করে তা পরীক্ষা করুন। যেহেতু সমস্যাটি একই সাথে সমস্ত ১৫০টি লোকেশনকে প্রভাবিত করছে, তাই এর কারণ সম্ভবত একটি সেন্ট্রালাইজড ফায়ারওয়াল পলিসি পরিবর্তন বা একটি Purple RADIUS সার্ভার IP অ্যাড্রেস পরিবর্তন যা Meraki কনফিগারেশনে আপডেট করা হয়নি।
অনুশীলনী প্রশ্নসমূহ
Q1. একটি ৫,০০০ আসনের ভেন্যুতে একটি বড় কনফারেন্স চলাকালীন, IT টিম রিপোর্ট পায় যে শত শত অংশগ্রহণকারী অতিথি WiFi পোর্টাল অ্যাক্সেস করতে পারছে না। অ্যাক্সেস পয়েন্টগুলো স্বাভাবিক অ্যাসোসিয়েশন সংখ্যা দেখাচ্ছে। সমস্যাটি ইভেন্ট শুরু হওয়ার ৪৫ মিনিট পরে শুরু হয়েছিল। এর সবচেয়ে সম্ভাব্য কারণ কী এবং তাৎক্ষণিক সমাধান কী?
ইঙ্গিত: সমস্যাটি ইভেন্ট শুরু হওয়ার পরে শুরু হয়েছিল, লঞ্চের সময় নয়। আরও ডিভাইস যুক্ত হওয়ার সাথে সাথে কোন রিসোর্সটি সীমাবদ্ধ হয়ে পড়ে তা বিবেচনা করুন।
মডেল উত্তর দেখুন
সবচেয়ে সম্ভাব্য কারণটি হলো DHCP পুলের ঘাটতি। যখন দর্শকরা এসে SSID-এর সাথে যুক্ত হতে শুরু করেন, তখন DHCP পুলটি পূর্ণ হয়ে যায়। নতুন ডিভাইসগুলো অ্যাক্সেস পয়েন্টের সাথে যুক্ত হলেও কোনো IP অ্যাড্রেস পায় না, যার ফলে তারা Captive Portal-কে ট্রিগার করার জন্য প্রয়োজনীয় HTTP প্রোব পাঠাতে পারে না। তাৎক্ষণিক সমাধান হলো DHCP লিজের সময় কমিয়ে ১৫ মিনিট করা (যাতে চলে যাওয়া ডিভাইসগুলোর অ্যাড্রেস দ্রুত পুনরুদ্ধার করা যায়) এবং সম্ভব হলে একটি দ্বিতীয় সাবনেট যোগ করে পুলটি প্রসারিত করা। দীর্ঘমেয়াদী সমাধান হলো পরবর্তী ইভেন্টে গড় ডিভাইস সংখ্যার পরিবর্তে সর্বোচ্চ সমসাময়িক ডিভাইসের সংখ্যা অনুযায়ী DHCP পুলের আকার নির্ধারণ করা।
Q2. আপনি একটি রিটেল চেইনে Ubiquiti UniFi অ্যাক্সেস পয়েন্টগুলিতে Purple স্থাপন করেছেন। স্প্ল্যাশ পেজটি সমস্ত ডিভাইসে সঠিকভাবে লোড হচ্ছে। অতিথিরা ইমেল ক্যাপচার ফর্ম পূরণ করে একটি সফলতার বার্তা দেখতে পাচ্ছেন। কিন্তু তারা যখন ব্রাউজ করার চেষ্টা করছেন, তখন কোনো ইন্টারনেট অ্যাক্সেস পাচ্ছেন না। Purple ড্যাশবোর্ড সফল লগইন দেখাচ্ছে। আপনি প্রথমে কী পরীক্ষা করবেন?
ইঙ্গিত: ক্লাউড প্ল্যাটফর্মটি সফল অথেনটিকেশন রেকর্ড করেছে। ত্রুটিটি স্থানীয়ভাবে প্রয়োগ করার ধাপে রয়েছে।
মডেল উত্তর দেখুন
যেহেতু Purple-এর ড্যাশবোর্ড সফল লগইন দেখাচ্ছে, ক্লাউড অথেনটিকেশন ধাপটি সঠিকভাবে সম্পন্ন হয়েছে। ত্রুটিটি RADIUS অথরাইজেশন ধাপে রয়েছে - UniFi কন্ট্রোলারটি Purple-এর RADIUS সার্ভার থেকে Access-Accept বার্তাটি পাচ্ছে না বা সেটির ওপর কাজ করছে না। এই ক্রমে পরীক্ষা করুন: (১) UniFi কন্ট্রোলারের RADIUS শেয়ার্ড সিক্রেটটি Purple-এর ড্যাশবোর্ডে থাকা সিক্রেটের সাথে হুবহু মিলছে কিনা; (২) কন্ট্রোলার থেকে Purple-এর RADIUS সার্ভার IP অ্যাড্রেসগুলিতে ১৮১২ এবং ১৮১৩ পোর্টে আউটবাউন্ড UDP অনুমোদিত কিনা; (৩) UniFi কন্ট্রোলারে কনফিগার করা RADIUS সার্ভার IP অ্যাড্রেসগুলো আপ-টু-ডেট আছে কিনা (Purple হয়তো সেগুলো আপডেট করেছে)। কন্ট্রোলারে একটি প্যাকেট ক্যাপচার করলে নিশ্চিত হওয়া যাবে Access-Accept বার্তাটি পৌঁছাচ্ছে কিনা।
Q3. একটি হোটেলের IT ম্যানেজার জানিয়েছেন যে অতিথিরা তাদের ডিভাইসে VPN ব্যবহার করলে তারা কোনোভাবেই Captive Portal-এ প্রবেশ করতে পারছেন না। VPN ছাড়া অতিথিরা স্বাভাবিকভাবে সংযোগ করতে পারছেন। হোটেলটি Cisco Meraki MX অ্যাপ্লায়েন্স ব্যবহার করে। VPN ব্যবহারকারীদের সুবিধা দিতে IT টিমের কি Captive Portal কনফিগারেশনে পরিবর্তন আনা উচিত?
ইঙ্গিত: Captive Portal ইন্টারসেপ্ট করার আগে একটি VPN ডিভাইসের নেটওয়ার্ক ট্রাফিকের ওপর কী প্রভাব ফেলে তা বিবেচনা করুন।
মডেল উত্তর দেখুন
না - Captive Portal কনফিগারেশন পরিবর্তন করার প্রয়োজন নেই। একটি VPN ক্লায়েন্ট ডিভাইস থেকে ট্রাফিক বের হওয়ার আগেই HTTP কানেক্টিভিটি প্রোব সহ সমস্ত ট্রাফিক এনক্রিপ্ট করে ফেলে। গেটওয়ে এনক্রিপ্ট করা VPN ট্রাফিক ইন্টারসেপ্ট করতে পারে না, তাই এটি কখনোই ৩০২ রিডাইরেক্ট ইস্যু করে না। অতিথিকে অবশ্যই তাদের VPN নিষ্ক্রিয় করতে হবে, Captive Portal অথেনটিকেশন সম্পন্ন করতে হবে এবং তারপর পুনরায় VPN সক্রিয় করতে হবে। এটি Captive Portal এবং VPN-এর একটি মৌলিক আর্কিটেকচারাল সীমাবদ্ধতা, কোনো কনফিগারেশন ত্রুটি নয়। IT টিমের উচিত অতিথি WiFi নির্দেশিকায় একটি নোট যুক্ত করা যা VPN ব্যবহারকারীদের সংযোগ করার আগে তাদের VPN নিষ্ক্রিয় করার পরামর্শ দেয়।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
Why does the captive portal redirect fail to open automatically on mobile devices?
Mobile operating systems (iOS, Android, Windows) rely on unauthenticated HTTP probes to vendor endpoints (such as captive.apple.com or connectivitycheck.gstatic.com/generate_204). If the network gateway does not intercept port 80 traffic with a clean HTTP 302 redirect, or if DNS queries for those probe domains are dropped before authentication, the Captive Network Assistant (CNA) will not launch.
Why does the 'captive portal login keeps stopping' error occur on Android devices?
The 'captive portal login keeps stopping' error on Android occurs when the system WebView crashes during redirection or when the gateway drops the generate_204 HTTP probe midway through authentication. Clearing the cache of the Android System WebView or Chrome app, disabling randomized MAC addresses for the venue SSID, and navigating manually to an unencrypted HTTP probe address resolves the crash loop.
How do unencrypted HTTP sites like neverssl.com force a captive portal login screen to load?
Because modern browsers enforce HTTP Strict Transport Security (HSTS) on encrypted domains like google.com, wireless gateways cannot intercept HTTPS traffic without triggering browser certificate warnings. Navigating to an unencrypted HTTP destination such as http://neverssl.com or http://1.1.1.1 sends a plaintext request that the gateway can safely intercept with an HTTP 302 redirect to the login splash page.
Why do Android devices show 'Sign into network' errors or fail the generate_204 probe?
Android devices query clients3.google.com/generate_204 and connectivitycheck.gstatic.com. If the wireless controller or walled garden blocks access to Google IP addresses without intercepting the HTTP request with a 302 redirect, Android detects a connection error or assumes an isolated intranet, suppressing the portal prompt. Whitelisting the required probe domains or ensuring transparent HTTP redirection resolves this.
How do you prevent HTTPS certificate warnings when intercepting captive portal traffic?
When a guest browser navigates to an HTTPS domain prior to login, intercepting the TLS handshake triggers severe browser security warnings (such as NET::ERR_CERT_COMMON_NAME_INVALID) due to HSTS and certificate mismatch. Enterprise networks prevent this by leaving HTTPS traffic undisturbed and relying exclusively on plaintext HTTP probe interception to trigger the operating system's native captive portal browser.
What causes RADIUS authentication timeouts during captive portal guest login?
RADIUS timeouts occur when the wireless access point or controller fails to receive a RADIUS Access-Accept packet from the authentication server within the timeout window (typically 5 seconds). Common causes include outbound UDP ports 1812 and 1813 being filtered by perimeter firewalls, mismatched RADIUS shared secrets, or asymmetric routing between the access point and the cloud RADIUS service.
How does RFC 8910 (Captive Portal API) resolve modern captive portal connection issues?
RFC 8910 standardizes captive portal discovery via DHCP Option 114 and IPv6 Router Advertisements. Rather than intercepting DNS queries or HTTP packets, the network directly advertises the captive portal API endpoint URL to connecting client devices. Modern operating systems query this API directly, eliminating HSTS certificate collisions, DNS hijacking latency, and CNA browser rendering bugs.
How does MAC address randomisation affect captive portal reconnection?
iOS 14+ and Android 10+ rotate private MAC addresses periodically or when re-associating with SSIDs. If a guest network tracks sessions solely by physical MAC address, returning visitors are forced to authenticate repeatedly. Enterprise platforms like Purple solve this by tying session authorisation to user identity tokens and Passpoint (Hotspot 2.0) profiles rather than transient hardware MACs.
How does Purple resolve captive portal redirect failures across multi-vendor networks?
Purple operates as a hardware-agnostic cloud overlay across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Fortinet, and UniFi hardware. By automating walled garden configurations, managing trusted SSL redirect domains, and providing high-availability cloud RADIUS clusters with sub-second failover, Purple eliminates captive portal redirect drops and delivers reliable guest onboarding.
এই সিরিজে পড়া চালিয়ে যান
Ubiquiti UniFi গেস্ট পোর্টাল রিডাইরেক্ট হচ্ছে না: কারণ এবং সমাধান
এই নির্দেশিকাটি গেস্ট স্টেট, রিডাইরেক্ট, প্রি-অথোরাইজেশন রুট এবং কন্ট্রোলার অথোরাইজেশন ধারাবাহিকভাবে অনুসরণ করে একটি UniFi গেস্ট পোর্টাল রিডাইরেক্ট ব্যর্থতা আলাদা করে চিহ্নিত করে। এটি ভেন্যু আইটি টিমগুলোকে গেস্ট নেটওয়ার্ক বনাম Hotspot বিভ্রান্তি, এক্সটার্নাল পোর্টাল হ্যান্ড-অফ, বর্তমান UniFi OS অ্যাকাউন্ট প্রয়োজনীয়তা এবং DNS আইসোলেশন টেস্টিং সমাধানের জন্য একটি বিশ্বস্ত পদ্ধতি প্রদান করে।
Cisco Meraki splash page কাজ করছে না: একটি ট্রাবলশুটিং ফ্লোচার্ট
এই ব্যবহারিক ডে-টু গাইডটি সনাক্ত করে যে একটি Cisco Meraki splash ফ্লো কোথায় ব্যর্থ হয়েছে: ক্লায়েন্ট অথরাইজেশন, HTTP redirect ইনিশিয়েশন, walled-garden রিচিবিলিটি বা RADIUS sign-on। এটি ভেন্যু আইটি টিমকে একটি নিয়ন্ত্রিত প্রমাণের পথ প্রদান করে, যাতে তারা কোনো লাইভ এস্টেটে বড় ধরণের পরিবর্তন না করেই Guest WiFi পুনরুদ্ধার করতে পারে।
Enterprise Guest WiFi সেটআপ নির্দেশিকা: VLAN Segmentation, নিরাপত্তা এবং Captive Portals
এই প্রযুক্তিগত নির্দেশিকাটি IT টিমগুলোকে দেখায় কীভাবে VLAN segmentation, firewall policy এবং একটি captive portal ব্যবহার করে Guest WiFi-কে একটি নিয়ন্ত্রিত ইন্টারনেট-অ্যাক্সেস পরিষেবা হিসেবে সেট আপ করতে হয়। এটি আরও ব্যাখ্যা করে যে কীভাবে Purple-এর রেজিস্ট্রেশন ফর্ম এবং অনবোর্ডিং নিয়ন্ত্রণগুলো স্টাফ, পেমেন্ট এবং অপারেশনাল সিস্টেমের চারপাশের সীমানাকে দুর্বল না করে একটি আনুপাতিক ভিজিটর অভিজ্ঞতা প্রদান করতে সহায়তা করে।
আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?
আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।