ক্যাপটিভ পোর্টাল রিডাইরেক্ট ট্রাবলশুটিং: গেস্ট WiFi কানেকশন ব্যর্থতা সমাধান করা
গেস্ট WiFi কানেক্টেড দেখানো সত্ত্বেও কেন ইন্টারনেট কাজ করছে না, তা আপনি স্ট্যাকের প্রতিটি স্তর পরীক্ষা করে নির্ণয় করতে পারবেন: অ্যাড্রেসিং, DNS, প্রোব রিডাইরেক্ট, ওয়াল্ড গার্ডেন এবং RADIUS। এরপর আপনি সমস্যার লক্ষণের সাথে তার মূল কারণ মিলিয়ে নিতে পারবেন, আপনার কাছে থাকা হার্ডওয়্যারের কনফিগারেশনে এটি ঠিক করতে পারবেন এবং এমন পরিবর্তন নিয়ন্ত্রণ ব্যবস্থা গড়ে তুলতে পারবেন যা ত্রুটিটি পুনরায় ঘটা প্রতিরোধ করবে।
Video overview
এই গাইডটি শুনুন
পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
আমাদের মূল সিরিজের অংশ: ক্যাপটিভ পোর্টাল গাইড →
গেস্ট WiFi কানেক্টেড দেখালেও যখন ইন্টারনেট থাকে না, তখন ডিভাইসটি নেটওয়ার্কে যুক্ত হয়েছে কিন্তু ক্যাপটিভ পোর্টাল রিডাইরেক্ট ক্ষতিগ্রস্ত হয়েছে। সাধারণ কারণগুলির মধ্যে রয়েছে ব্লক করা অপারেটিং সিস্টেম প্রোব, অনুপস্থিত ওয়ার্ল্ড গার্ডেন এন্ট্রি অথবা ব্যর্থ হওয়া DNS। অন্যান্য কারণগুলির মধ্যে রয়েছে নিঃশেষিত DHCP পুল অথবা এমন একটি RADIUS Access-Accept যা কখনোই গেটওয়েতে পৌঁছায় না। কনফিগারেশনেই এই প্রতিটি সমস্যার সমাধান করা সম্ভব।
"গেস্ট WiFi কানেক্টেড কিন্তু ইন্টারনেট নেই" সমস্যাটি ঠিক কেমন দেখায়?
ডিভাইসটি নেটওয়ার্ক নামের (SSID) সাথে যুক্ত হয় এবং ফুল সিগন্যাল দেখায়, তবুও কিছুই লোড হয় না। প্রতিটি প্ল্যাটফর্ম এটি আলাদাভাবে রিপোর্ট করে:
- iOS নেটওয়ার্ক নামের নিচে "No Internet Connection" তালিকাভুক্ত করে।
- Android "Connected, no internet" অথবা একটি "Sign in to network" প্রম্পট দেখায় যা কোনো ফলাফল দেয় না।
- Windows নেটওয়ার্কটিকে "No internet" হিসাবে চিহ্নিত করে।
দর্শনার্থী একটি সচল WiFi আইকন এবং একটি অকার্যকর ব্রাউজার দেখতে পান, তাই তারা ভেন্যুটিকে দোষারোপ করেন।
একটি মাত্র উপসর্গ কয়েকটি ভিন্ন ব্যর্থতাকে লুকিয়ে রাখতে পারে। আপনি সাধারণত এই প্যাটার্নগুলির মধ্যে একটি দেখতে পাবেন:
- কোনো ডিভাইসেই লগইন পৃষ্ঠাটি কখনোই উপস্থিত হয় না।
- লগইন পৃষ্ঠাটি iPhones-এ উপস্থিত হয় কিন্তু Android ফোনে উপস্থিত হয় না, অথবা এর বিপরীতটা ঘটে।
- ব্রাউজারটি লগইন পৃষ্ঠার বদলে একটি সার্টিফিকেট বা প্রাইভেসির সতর্কতা দেখায়।
- দর্শনার্থী ফর্মটি পূরণ করেন, একটি সফল বার্তা দেখতে পান, তবুও ইন্টারনেট অ্যাক্সেস পান না।
- শান্ত সময়ে সবকিছু কাজ করে এবং ব্যস্ততম সময়ে ব্যর্থ হয়।
প্রতিটি প্যাটার্ন নেটওয়ার্কের একটি ভিন্ন স্তরের দিকে নির্দেশ করে। অ্যাক্সেস পয়েন্ট রিমেকার না করে প্যাটার্নটি পড়ে শুরু করুন।
ক্যাপটিভ পোর্টাল সনাক্তকরণ কীভাবে কাজ করে
একটি ক্যাপটিভ পোর্টাল হলো এমন একটি ওয়েব পেজ যা একটি গেটওয়ে ইন্টারনেট অ্যাক্সেস দেওয়ার আগে দেখায়। আপনার ডিজাইন অনুযায়ী গেটওয়ে হলো আপনার কন্ট্রোলার, ফায়ারওয়াল বা অ্যাক্সেস পয়েন্ট।
প্রতিটি প্রধান অপারেটিং সিস্টেম নেটওয়ার্কে যুক্ত হওয়ার সাথে সাথেই একটি ক্যাপটিভ পোর্টালের উপস্থিতি পরীক্ষা করে। এটি একটি পরিচিত ঠিকানায় একটি প্লেন HTTP অনুরোধ পাঠায় এবং তারা যা আশা করে তার সাথে উত্তরটি তুলনা করে। প্রতিটি ফলাফলের অর্থ আলাদা:
- উত্তরটি মিলে যায়। ডিভাইসটি ধরে নেয় যে এতে ওপেন ইন্টারনেট রয়েছে।
- গেটওয়ে একটি HTTP 302 রিডাইরেক্ট পাঠায়। ডিভাইসটি জানতে পারে যে এটি একটি পোর্টালের পিছনে রয়েছে। এটি একটি লাইটওয়েট ব্রাউজার উইন্ডো খোলে, যাকে প্রায়শই ক্যাপটিভ নেটওয়ার্ক অ্যাসিস্ট্যান্ট বলা হয়, এবং আপনার লগইন পৃষ্ঠাটি লোড করে।
- অনুরোধের কোনো উত্তর পাওয়া যায় না। ডিভাইসটি ইন্টারনেট নেই বলে রিপোর্ট করে এবং কিছুই খোলে না।
| প্ল্যাটফর্ম | প্রোব URL | অনলাইন থাকলে প্রত্যাশিত উত্তর |
|---|---|---|
| iOS এবং macOS | http://captive.apple.com/hotspot-detect.html |
একটি "Success" পেজ সহ HTTP 200 |
| Android | http://connectivitycheck.gstatic.com/generate_204 |
HTTP 204 নো কন্টেন্ট |
| Windows (NCSI) | http://www.msftconnecttest.com/connecttest.txt |
"Microsoft Connect Test" টেক্সট সহ HTTP 200 |
| Firefox | http://detectportal.firefox.com/success.txt |
"success" টেক্সট সহ HTTP 200 |
Microsoft তথ্য দেয় যে তার Network Connectivity Status Indicator (NCSI) একটি DNS চেক হিসাবে dns.msftncsi.com সমাধান করে। তাই HTTP কাজ করলেও প্রি-অথেন্টিকেশন DNS ক্ষতিগ্রস্ত হলে একটি Windows ল্যাপটপ ইন্টারনেট নেই বলে রিপোর্ট করতে পারে।
সাধারণ কী কারণে একটি ক্যাপটিভ পোর্টাল রিডাইরেক্ট ব্যর্থ হয়?
বেশিরভাগ ক্ষেত্রে সাতটি কারণ মূল ভূমিকা পালন করে। এগুলি অ্যাড্রেসিং থেকে শুরু করে অথেন্টিকেশন পর্যন্ত বিভিন্ন লেয়ারে অবস্থান করে।
অপারেটিং সিস্টেম প্রোব ব্লক হয়েছে
গেটওয়ের প্রি-অথেন্টিকেশন অ্যাক্সেস কন্ট্রোল লিস্ট (ACL) প্রোবটিকে রিডাইরেক্ট করার বদলে ড্রপ করে দেয়। ডিভাইসটি কোনো প্রতিক্রিয়া পায় না এবং ধরে নেয় কোনো ইন্টারনেট নেই। ফলে এটি কখনও ক্যাপটিভ পোর্টাল খোলে না।
একটি DNS ফিল্টারিং সার্ভিস যা প্রোব হোস্টনেমগুলিকে ব্লক করে, সেটির ফলাফলও একই হয়। পোর্টাল কখনও দৃশ্যমান না হওয়ার সবচেয়ে সাধারণ কারণ এটিই।
HTTPS এবং HSTS ইন্টারসেপশনে বাধা তৈরি করে
RFC 6797-এ সংজ্ঞায়িত HTTP স্ট্রিক্ট ট্র্যান্সপোর্ট সিকিউরিটি (HSTS) ব্রাউজারকে কেবল HTTPS-এর মাধ্যমেই কোনো ডোমেইনে পৌঁছানোর নির্দেশ দেয়। ব্রাউজারগুলিতে Google এবং বেশিরভাগ ব্যাংকের মতো HSTS ডোমেইনের একটি প্রিলোড তালিকা থাকে। যখন কোনো ভিজিটর google.com টাইপ করেন, ডিভাইস থেকে রিকোয়েস্ট পাঠানোর আগেই ব্রাউজার সেটিকে HTTPS-এ আপগ্রেড করে।
গেটোয়ে google.com-এর জন্য কোনো সার্টিফিকেট প্রদান না করে সেই রিকোয়েস্ট রিডাইরেক্ট করতে পারে না, যা মূলত গেটওয়ের কাছে থাকেই না। ব্রাউজার তখন একটি কঠিন সিকিউরিটি ওয়ার্নিং দেখায় এবং آگے এগোনোর কোনো উপায় থাকে না।
এর সমাধান হলো উপরের সারণীতে থাকা কেবল প্লেন HTTP প্রোবগুলিকেই রিডাইরেক্ট করা, যা ঠিক এই উদ্দেশ্যেই তৈরি করা হয়েছে। পোর্টাল রিডাইরেকশনের জন্য কখনও HTTPS ইন্টারসেপ্ট করবেন না।
ওয়াল্ড গার্ডেন খুব সীমিত
একটি ডিভাইস অথেন্টিকেট করার আগে যে সমস্ত ডোমেইন এবং IP অ্যাড্রেসে পৌঁছাতে পারে, তার তালিকাই হলো ওয়াল্ড গার্ডেন। কোনো এন্ট্রি অনুপস্থিত থাকলে, লগইন পেজটি আংশিকভাবে লোড হয় অথবা সাইন-ইন ধাপটি ব্যর্থ হয়। সাধারণত যে জায়গাগুলিতে ত্রুটি থাকে:
- সোশ্যাল বা সিঙ্গেল সাইন-অন লগইনের জন্য আইডেন্টিটি প্রোভাইডার এন্ডপয়েন্ট, যেমন Microsoft Entra ID, Okta বা Google Workspace।
- কনটেন্ট ডেলিভারি নেটওয়ার্ক ডোমেইন যা আপনার লগইন পেজের ফন্ট, স্ক্রিপ্ট এবং স্টাইলশিট পরিবেশন করে।
- পেমেন্ট প্রসেসর ডোমেইন, যদি আপনি অ্যাক্সেসের জন্য চার্জ নেন।
- Purple-এর ক্যাপটিভ পোর্টাল এবং RADIUS এন্ডপয়েন্ট, যা আপনার হার্ডওয়্যারের জন্য Purple-এর ইন্টিগ্রেশন গাইডে তালিকাভুক্ত করা হয়েছে।
অথেন্টিকেশনের আগে DNS ব্যর্থ হয়
পেজ লোড করার আগে ডিভাইসটিকে অবশ্যই পোর্টাল হোস্টনেম সমাধান করতে হবে। দুটি ক্ষেত্রে রিডাইরেক্ট কোথাও পৌঁছায় না:
- গেটওয়ে প্রি-অথেন্টিকেশন স্টেটে DNS ব্লক করে।
- DHCP এমন একটি DNS সার্ভার প্রদান করে যেখানে ডিভাইসটি পৌঁছাতে পারে না।
Android একটি নতুন জটিলতা তৈরি করে। কোনো ভিজিটর যদি একটি নির্দিষ্ট প্রাইভেট DNS হোস্টনেম সেট করে থাকেন, তবে Android পোর্ট 853-এ DNS over TLS প্রত্যাশা করে। স্বয়ংক্রিয় মোডে এটি সাধারণ DNS-এ ফিরে যায়।
DHCP পুল নিঃশেষ হয়ে গেছে
অ্যাড্রেস পুল শেষ হয়ে গেলে, একটি নতুন ডিভাইস অ্যাক্সেস পয়েন্টের সাথে যুক্ত হয় কিন্তু কোনো IP অ্যাড্রেস পায় না। Windows তখন নিজেকে একটি 169.254.x.x লিংক-লোকাল অ্যাড্রেস বরাদ্দ করে, এবং অন্যান্য সিস্টেমগুলিও একই রকম সেলফ-অ্যাসাইনড স্টেট দেখায়।
কোনো বৈধ অ্যাড্রেস না থাকলে, ডিভাইসটি কোনো প্রোব পাঠাতে পারে না। এটি কানেক্টেড দেখালেও কোনো ইন্টারনেট থাকে না। স্টেডিয়াম, কনফারেন্স সেন্টার এবং ট্রান্সপোর্ট হাবগুলিতে পিক-টাইমে এটিই ক্লাসিক ব্যর্থতার কারণ।
RADIUS কখনও Access-Accept ডেলিভার করে না
RADIUS (রিমোট অথেন্টিকেশন ডায়াল-ইন ইউজার সার্ভিস) অথেন্টিকেশন সার্ভার থেকে আপনার গেটওয়েতে লগইন সিদ্ধান্ত বহন করে নিয়ে যায়। RFC 2865-এ সংজ্ঞায়িত সার্ভারটি Access-Accept বা Access-Reject উত্তর দেয়। গেটওয়ে তখন অ্যাক্সেস উন্মুক্ত করে অথবা বন্ধ রাখে।
একজন ভিজিটর যিনি ফর্মটি পূরণ করেছেন কিন্তু অফলাইনে রয়ে গেছেন, তার অর্থ সাধারণত গেটওয়ে Access-Accept মিস করেছে। এর তিনটি সাধারণ কারণ হলো:
- অমিল থাকা একটি শেয়ার্ড সিক্রেট।
- ফায়ারওয়াল যা UDP 1812 (অথেন্টিকেশন) বা UDP 1813 (অ্যাকাউন্টিং) ব্লক করছে। RFC 2865 এবং RFC 2866 এই পোর্টগুলিকে সংজ্ঞায়িত করে।
- কন্ট্রোলারে ভুল সার্ভার অ্যাড্রেস।
পোর্টালের নিজস্ব সার্টিফিকেটের মেয়াদ শেষ হয়ে গেছে
আপনার লগইন পৃষ্ঠাটি HTTPS-এর মাধ্যমে প্রদর্শিত হয়। এর TLS সার্টিফিকেটের মেয়াদ শেষ হয়ে গেলে, প্রতিটি আধুনিক ব্রাউজার একটি সুরক্ষা সতর্কতা সহ পৃষ্ঠাটিকে ব্লক করে দেয়। রিডাইরেক্ট পুরোপুরি কাজ করে, তাও ভিজিটর সাইন ইন করতে পারেন না।
সমস্যাটির আসল কারণ কী তা আপনি কীভাবে চিহ্নিত করবেন?
ক্রম অনুসারে স্ট্যাক ধরে কাজ করুন। প্রতিটি পরীক্ষা একটি করে লেয়ার বাতিল করে, তাই প্রথম ব্যর্থতাতেই থামুন।
- ডিভাইসটিতে কি একটি বৈধ IP অ্যাড্রেস আছে? Windows-এ
ipconfig /allচালান, অথবা কোনো ফোনে নেটওয়ার্ক সংক্রান্ত বিবরণ চেক করুন। একটি 169.254.x.x অ্যাড্রেস, অথবা কোনো অ্যাড্রেসই না থাকার বিষয়টি DHCP-এর দিকে নির্দেশ করে। DHCP সার্ভারে পুলের ব্যবহার চেক করুন। 90%-এর উপরে থাকলে, আপনি প্রায় শেষ সীমার কাছাকাছি আছেন। - DNS কি রিজলভ করছে? গেস্ট ভার্চুয়াল LAN (VLAN)-এর কোনো ডিভাইস (একটি যুক্তিসঙ্গতভাবে আলাদা নেটওয়ার্ক সেগমেন্ট) থেকে পোর্টাল হোস্টনেম খুঁজুন। অনুসন্ধানটি ব্যর্থ হলে, প্রি-অথেন্টিকেশন DNS ব্লক করা আছে অথবা DHCP-অ্যাসাইন করা DNS সার্ভারটি ভুল।
- প্রোবটি কি 302 পাচ্ছে? গেস্ট VLAN-এ একটি প্যাকেট ক্যাপচার নিন, অথবা HTTP প্রোব URL-গুলির একটি ব্রাউজ করুন। আপনার প্রোবটি দেখা উচিত, তারপর একটি HTTP 302 পোর্টালে নির্দেশ করা উচিত। কোনো উত্তর ছাড়া একটি প্রোবের অর্থ হলো ACL এটি ড্রপ করেছে। কোনো প্রোবই না থাকার অর্থ হলো ডিভাইসটি মনে করছে এটি ইতিমধ্যেই অনলাইনে রয়েছে, যা প্রায়শই ক্যাশড স্টেট থেকে হয়। নেটওয়ার্কটি Forget করুন এবং পুনরায় যুক্ত হন।
- লগইন পৃষ্ঠাটি কি পুরোপুরি লোড হচ্ছে? ব্রাউজার ডেভেলপার টুলস (F12) খুলুন এবং নেটওয়ার্ক ট্যাবটি লক্ষ্য করুন। তৃতীয় পক্ষের ডোমেনে ব্লক করা রিকোয়েস্ট ওয়াল্ড গার্ডেনের ঘাটতি প্রকাশ করে।
- গেটওয়ে কি Access-Accept গ্রহণ করছে? কন্ট্রোলারের RADIUS লগগুলি চেক করুন। একটি সফল লগইনের পরে Start স্ট্যাটাস সহ একটি Accounting-Request আসে। লগইনের পর কোনো অ্যাকাউন্টিং রেকর্ড না আসলে, RADIUS পাথটি ক্ষতিগ্রস্ত।
তারপর আপনি যা দেখছেন তা এই টেবিলের সাথে মিলিয়ে নিন।
| লক্ষণ | সম্ভাব্য কারণ | সমাধান |
|---|---|---|
| কোনো ডিভাইসেই পোর্টাল দৃশ্যমান হচ্ছে না | গেটওয়ে ACL বা DNS ফিল্টার দ্বারা প্রোব ব্লক করা হয়েছে | অথেন্টিকেশনের আগে প্রোব হোস্টনেম অনুমতি দিন এবং সেগুলি রিডাইরেক্ট করুন |
| পোর্টাল iOS-এ দেখা যাচ্ছে, Android-এ নয় | রিডাইরেক্ট রুলস থেকে Android প্রোব হোস্ট নিখোঁজ রয়েছে | connectivitycheck.gstatic.com রিডাইরেক্ট করুন এবং পুনরায় পরীক্ষা করুন |
| পোর্টালের পরিবর্তে সার্টিফিকেট সতর্কতা আসছে | HTTPS ইন্টারসেপশন, বা মেয়াদ শেষ হওয়া পোর্টাল সার্টিফিকেট | কেবল HTTP প্রোব রিডাইরেক্ট করুন, এবং সার্টিফিকেট রিনিউ করুন |
| ছবি বা বোতাম ছাড়া পোর্টাল লোড হচ্ছে | কন্টেন্ট ডেলিভারি নেটওয়ার্ক ডোমেন ব্লক করা হয়েছে | লগইন পৃষ্ঠার অ্যাসেট ডোমেনগুলি ওয়াল্ড গার্ডেনে যোগ করুন |
| সোশ্যাল লগইন গোপনে ব্যর্থ হচ্ছে | আইডেন্টিটি প্রোভাইডার এন্ডপয়েন্টগুলি অনুপস্থিত রয়েছে | Microsoft Entra ID, Okta বা Google Workspace এন্ডপয়েন্টগুলি যোগ করুন |
| লগইন সফল হয়েছে, কিন্তু ইন্টারনেট নেই | Access-Accept গেটওয়েতে পৌঁছাচ্ছে না | শেয়ার্ড সিক্রেট, UDP 1812 এবং 1813, এবং সার্ভার অ্যাড্রেস চেক করুন |
| দর্শকরা প্রতিবার ভিজিট করার সময় সাইন ইন করতে বাধ্য হচ্ছেন | সংক্ষিপ্ত সেশন, বা র্যান্ডমাইজড MAC অ্যাড্রেস | সেশন দীর্ঘ করুন এবং MAC র্যান্ডমাইজেশনের পরিকল্পনা করুন |
| কেবল পিক টাইমে ব্যর্থতা দেখা যাচ্ছে | DHCP পুল শেষ হয়ে গেছে | সাবনেট বড় করুন এবং লিজের সময় কমান |
একটি বাস্তব উদাহরণ: পিক টাইমে ১,৫০০টি আসন বিশিষ্ট একটি কনফারেন্স সেন্টার
পরিস্থিতি। একটি কনফারেন্স সেন্টার আট ঘণ্টার DHCP লিজ সহ একটি একক /24 সাবনেটে তাদের অতিথিদের নেটওয়ার্ক চালাচ্ছিল। সকালের কি-নোট সেশনগুলি মসৃণভাবে পরিচালিত হয়েছিল। দুপুরের খাবারের পর, বিকেলের সেশনের জন্য আসা অতিথিরা "সংযুক্ত, কোনো ইন্টারনেট নেই" দেখতে পান। হেল্প ডেসক এটিকে একটি পোর্টাল ত্রুটি হিসাবে বিবেচনা করে এবং কন্ট্রোলারটি দুবার রিস্টার্ট করে।
কী করা হয়েছিল। ডায়াগনোসিসের ১ম ধাপে দেখা গেছে যে নতুন ডিভাইসগুলি 169.254.x.x অ্যাড্রেস ধরে রাখছিল। একটি /24 সাবনেট ২৫৪টি ব্যবহারযোগ্য অ্যাড্রেস প্রদান করে, এবং আট ঘণ্টার লিজ সকালের প্রতিটি অ্যাড্রেস সংরক্ষিত রেখেছিল। টিমটি অতিথিদের VLAN একটি /21-এ স্থানান্তরিত করে এবং লিজ কমিয়ে ৩০ মিনিট করে দেয়।
ফলাফল। ব্যবহারযোগ্য অ্যাড্রেস ২৫৪ থেকে বেড়ে ২,০৪৬ হয়েছে, যা আগের ক্ষমতার প্রায় আট গুণ। একজন চলে যাওয়া অতিথির ফেলে যাওয়া অ্যাড্রেস এখন আট ঘণ্টার বদলে ৩০ মিনিটের মধ্যে পুলে ফিরে আসে। সংশোধনটি কেবল একটি চেঞ্জ উইন্ডোর মধ্যে করা সম্ভব হয়েছিল এবং এতে কোনো নতুন হার্ডওয়্যার লাগেনি।
একটি বাস্তব উদাহরণ: একটি ২০০টি রুমের হোটেল যেখানে Android অতিথিরা সাইন ইন করতে পারছিলেন না
পরিস্থিতি। লগইন পেজ পুনরায় ডিজাইন করার পর, ২০০টি রুমের একটি হোটেল Android অতিথিদের কাছ থেকে ফ্রন্ট ডেস্কে অভিযোগ পায়। তাদের মধ্যে বেশিরভাগই Google সাইন-ইন বিকল্প বেছে নিয়েছিলেন। পোর্টালটি দৃশ্যমান হচ্ছিল, কিন্তু বোতামটি কাজ করছিল না।
কী করা হয়েছিল। আইটি ম্যানেজার একটি iPhone, একটি Android ফোন এবং একটি Windows ল্যাপটপে ফ্লো পরীক্ষা করেছেন। ল্যাপটপের ডেভেলপার টুলস থেকে দেখা গেছে যে একটি ফন্ট ডেলিভারি নেটওয়ার্ক এবং Google-এর সাইন-ইন ডোমেনে অনুরোধ ব্লক করা হয়েছে। নতুন ডিজাইনে উভয়কেই যোগ করা হয়েছিল। টিম এগুলিকে ওয়ল্ড গার্ডেনে যুক্ত করেছে।
ফলাফল। প্রথম পুনরায় পরীক্ষায় তিনটি টেস্ট ডিভাইসেই Google সাইন-ইন সফল হয়েছে। সংশোধনের জন্য দুটি ওয়াল্ড গার্ডেন এন্ট্রি প্রয়োজন হয়েছিল এবং কোনো হার্ডওয়্যার পরিবর্তনের প্রয়োজন পড়েনি।
একটি বাস্তব উদাহরণ: ফায়ারওয়াল রিফ্রেশের পর একটি ৪০-টি স্টোরের রিটেইল এস্টেট
পরিস্থিতি। একটি রিটেইলার সপ্তাহান্তে ৪০টি স্টোরের ফায়ারওয়াল পরিবর্তন করে। সোমবারে, প্রতিটি রিফ্রেশ করা স্টোরের গ্রাহকরা লগইন ফর্মটি পূরণ করতে পেরেছিলেন তবে অফলাইনে ছিলেন। যে স্টোরগুলি এখনও রিফ্রেশ করা হয়নি সেগুলি স্বাভাবিকভাবে কাজ করছিল।
কী করা হয়েছিল। ধাপ ৫-এ রিফ্রেশ করা স্টোরগুলি থেকে কোনো অ্যাকাউন্ট সংক্রান্ত রেকর্ড পাওয়া যায়নি। নতুন ফায়ারওয়াল টেমপ্লেটটি ডিফল্টভাবে আউটবাউন্ড UDP বাতিল করে দিয়েছিল, যা 1812 এবং 1813 ব্লক করছিল। টিম টেমপ্লেটে স্পষ্ট আউটবাউন্ড রুল যোগ করেছে এবং এটি ৪০টি স্টোরেই পুশ করেছে।
ফলাফল। পুশ করার পরে প্রতিটি স্টোর থেকে অ্যাকাউন্ট সংক্রান্ত রেকর্ড পুনরায় দৃশ্যমান হয়েছে। কারণ কেবল রিফ্রেশ করা স্টোরগুলি ব্যর্থ হয়েছিল, এই প্যাটার্নটি সরাসরি টেমপ্লেটের ত্রুটি নির্দেশ করেছিল এবং WiFi-কে বাদ দিয়েছিল।
আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?
আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।
প্রতিটি অপারেটিং সিস্টেম এবং কন্ট্রোলারে আপনি কীভাবে এটি সমাধান করবেন?
কন্ট্রোলার ফিক্স প্রতিটি প্ল্যাটফর্মেই একই প্যাটার্ন অনুসরণ করে। অপারেটিং সিস্টেমের ফিক্সগুলি মূলত প্রতিটি সিস্টেম কীভাবে আচরণ করে তা জানার ওপর নির্ভর করে।
আপনার কন্ট্রোলারে
Purple, Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet-এর ওপরে একটি ক্লাউড ওভারলে হিসেবে চলে। ফিক্স প্যাটার্নটি আটটিতেই এক ধরনের:
- অতিথি SSID-কে আপনার Purple ইন্টিগ্রেশন গাইড থেকে প্রাপ্ত এক্সটার্নাল ক্যাপটিভ পোর্টাল URL-এ পয়েন্ট করুন এবং সমস্ত লোকাল স্প্ল্যাশ পেজ নিষ্ক্রিয় করুন।
- প্রোব সহ সমস্ত আনঅথেন্টিকেটেড HTTP ট্রাফিককে সেই URL-এ রিডাইরেক্ট করুন। HTTPS যেমন আছে তেমনই রাখুন।
- অথেন্টিকেশনের পূর্বে DNS এবং DHCP-র অনুমতি দিন।
- ওয়াল্ড গার্ডেন এন্ট্রিগুলি যোগ করুন: Purple এন্ডপয়েন্ট, আইডেন্টিটি প্রোভাইডার এন্ডপয়েন্ট এবং লগইন পেজ অ্যাসেট ডোমেন।
- আপনার Purple ড্যাশবোর্ড থেকে RADIUS সার্ভার অ্যাড্রেস এবং শেয়ার্ড সিক্রেট লিখুন। তারপর নিশ্চিত করুন যে ফায়ারওয়াল আউটবাউন্ড UDP 1812 এবং 1813-এর অনুমতি দিচ্ছে।
ভেন্ডর এবং ফার্মওয়্যার ভার্সনের ওপর ভিত্তি করে মেনুর নাম ভিন্ন হতে পারে, তাই আপনার প্ল্যাটফর্মের জন্য Purple-এর ইন্টিগ্রেশন গাইড অনুসরণ করুন। FortiGate ক্যাপটিভ পোর্টাল ফ্লো সম্পর্কিত Fortinet-এর কমিউনিটি ডকুমেন্টেশন রিডাইরেক্ট সিকোয়েন্সের জন্য একটি দরকারী ভেন্ডর-সাইড রেফারেন্স।
iOS এবং macOS-এ
যদি ক্যাপটিভ নেটওয়ার্ক অ্যাসিস্ট্যান্ট না খোলে, তবে Settings থেকে নেটওয়ার্কটি "forget" করুন এবং পুনরায় যুক্ত হন। এটি একটি নতুন প্রোব পাঠাতে বাধ্য করে।
সাম্প্রতিক iOS এবং macOS রিলিজগুলিতে Captive Portal API সমর্থিত। এটি RFC 8910-এ সংজ্ঞায়িত DHCP বিকল্প 114-এর মাধ্যমে নেটওয়ার্ককে তার পোর্টাল বিজ্ঞাপন করার অনুমতি দেয়, যা ইন্টারসেপশনের ওপর নির্ভরতা কমায়। যদি অ্যাসিস্ট্যান্ট খোলে কিন্তু ফাঁকা থাকে, তবে অ্যাসেট ডোমেনের জন্য ওয়াল্ড গার্ডেন পরীক্ষা করুন।
Android-এ
Android একটি পোর্টাল শনাক্ত করলে "Sign in to network" নোটিফিকেশন দেখায়। যদি নোটিফিকেশনটি না আসে, তবে গেটওয়েটি connectivitycheck.gstatic.com ড্রপ করার বদলে রিডাইরেক্ট করছে কিনা তা নিশ্চিত করুন।
যদি কোনো ভিজিটর "Private DNS server cannot be accessed" দেখতে পান, তবে তাদের ফোনে একটি কঠোর Private DNS হোস্টনেম সেট করা রয়েছে। আপনার কাছে দুটি বিকল্প রয়েছে:
- অথেন্টিকেশনের আগে পোর্ট 853-এ DNS over TLS-এর অনুমতি দিন।
- ভিজিটরকে Private DNS স্বয়ংক্রিয় বা "automatic"-এ পরিবর্তন করতে বলুন।
Windows-এ
Windows NCSI HTTP প্রোব এবং এর DNS চেকের ওপর নির্ভর করে। যদি পোর্টালটি স্বয়ংকৃয়ভাবে না খোলে, ম্যানুয়ালি রিডাইরেক্ট ট্রিগার করতে যেকোনো প্লেন HTTP সাইট ব্রাউজ করুন। লগইনের পরেও "No internet" লেখা থাকার অর্থ সাধারণত গেটওয়ে এখনও প্রোবটিকে রিডাইরেক্ট করছে। সেই ক্ষেত্রে, গেটওয়েটি Access-Accept প্রয়োগ করেনি।
ব্রাউজারে
ফ্রন্ট-লাইন কর্মীদের নির্দেশ দিন তারা যেন ভিজিটরদের একটি HTTP ঠিকানায় পাঠান, কখনও google.com-এর মতো কোনো HSTS ডোমেনে নয়। Firefox, detectportal.firefox.com-এর বিরুদ্ধে নিজস্ব প্রোব চালায়, তাই আপনার রিডাইরেক্ট টেস্টে সেই হোস্টটি অন্তর্ভুক্ত করুন।
কীভাবে আপনি অতিথিদের WiFi রিডাইরেক্ট ব্যর্থতা পুনরায় হওয়া বন্ধ করবেন?
বেশিরভাগ পুনরাবৃত্ত ঘটনা পরিবর্তন থেকে আসে, মূল বিল্ড থেকে নয়। একটি ফার্মওয়্যার আপডেট, একটি নতুন ফায়ারওয়াল টেমপ্লেট, একটি লগইন পেজ রেডিসাইন বা একটি মেয়াদোত্তীর্ণ সার্টিফিকেট টেস্টিং এড়িয়ে বেরিয়ে যায়। আপনার পরিবর্তন প্রক্রিয়ায় এই নিয়ন্ত্রণগুলি অন্তর্ভুক্ত করুন:
- প্রতিটি পরিবর্তনের পর তিনটি প্ল্যাটফর্মে টেস্ট করুন। একটি iPhone, একটি Android ফোন এবং একটি Windows ল্যাপটপ ব্যবহার করুন। অন্যগুলি পাস করার সময় যদি একটি প্ল্যাটফর্ম ব্যর্থ হয়, তবে প্রথমে ওয়াল্ড গার্ডেন গ্যাপ পরীক্ষা করুন।
- গড় নয়, পিক ক্ষমতার জন্য আকার নির্ধারণ করুন। একই সাথে সংযুক্ত ডিভাইসের সর্বাধিক সংখ্যা গণনা করুন এবং অতিরিক্ত ক্ষমতা যুক্ত করুন। ক্ষণস্থায়ী ভিজিটর নেটওয়ার্কগুলি সাধারণত 15 থেকে 30 মিনিটের লিজ চালায়।
- ভিজিটের সাথে মিল রেখে সেশন সেট করুন। হসপিটালিটি এবং রিটেল ভেন্যুগুলি সাধারণত 24 ঘন্টার সেশন সেট করে, যাতে একজন অতিথি প্রতি স্টে বা ভিজিটে একবার সাইন ইন করেন।
- প্রতিদিন লগইন ভলিউমের দিকে নজর রাখুন। Purple-এর WiFi Analytics ভেন্যু অনুযায়ী লগইনের রিপোর্ট দেয়। একটি নির্দিষ্ট সাইটে হঠাৎ লগইন কমে যাওয়া আপনাকে একটি RADIUS বা ওয়াল্ড গার্ডেন ত্রুটি সম্পর্কে সতর্ক করে, যা প্রায়শই ভিজিটররা অভিযোগ করার আগেই বোঝা যায়।
- সার্টিফিকেট এবং শেয়ার করা সিক্রেটগুলি চেঞ্জ কন্ট্রোলের অধীনে রাখুন। পোর্টাল সার্টিফিকেটের মেয়াদ শেষের তারিখের ডায়রি মেইনটেইন করুন। RADIUS শেয়ার করা সিক্রেটটি এমন জায়গায় স্টোর করুন যেখানে ফায়ারওয়াল এবং কন্ট্রোলার দল উভয়েই চেক করতে পারে।
- গেস্ট ট্র্যাফিক সেগমেন্ট করুন। অতিথিদের নিজস্ব VLAN-এ রাখুন। PCI DSS কার্ডহোল্ডার ডাটা এনভায়রনমেন্টের আওতার বাইরে একটি গেস্ট নেটওয়ার্ক রাখার উপায় হিসেবে সেগমেন্টেশনকে দেখে।
- MAC র্যান্ডমাইজেশনের জন্য পরিকল্পনা করুন। সাম্প্রতিক iOS এবং Android রিলিজগুলি প্রতিটি নেটওয়ার্কের জন্য একটি র্যান্ডম MAC অ্যাড্রেস ব্যবহার করে এবং কিছু মোড সময়ের সাথে সাথে এটি রোটেট করে। MAC অ্যাড্রেসের ওপর কি (keyed) করা সেশন ক্যাশিং তখন ফিরে আসা ভিজিটরদের আবার সাইন ইন করতে বলবে।
- সঠিকভাবে কনসেন্ট বা সম্মতি সংগ্রহ করুন। GDPR-এর জন্য মার্কেটিং ডাটার ক্ষেত্রে জেনেশুনে দেওয়া, ইতিবাচক সম্মতির প্রয়োজন হয়। Purple-এর কনশাস-চয়েস অপ্ট-ইনগুলি প্রতিটি উদ্দেশ্যের জন্য একটি পৃথক পছন্দ উপস্থাপন করে।
ক্যাপটিভ পোর্টাল থেকে পুনরাগত ভিজিটরদের সরিয়ে নিন
সবচেয়ে স্থায়ী সমাধানটি পুনরাবৃত্ত ভিজিটের জন্য রিডাইরেক্ট পুরোপুরি সরিয়ে দেয়।
- Passpoint হলো হটস্পট 2.0 স্পেসিফিকেশনের ওপর তৈরি ইন্ডাস্ট্রি সার্টিফিকেশন। এটি স্টোর করা প্রোফাইল ব্যবহার করে একটি ডিভাইসকে স্বয়ংক্রিয়ভাবে একটি নেটওয়ার্কে যুক্ত হতে দেয়।
- Wireless Broadband Alliance দ্বারা পরিচালিত OpenRoaming, আইডেন্টিটি প্রোভাইডারদের ফেডারেট করে। ভিজিটরদের বিদ্যমান ক্রেডেনশিয়াল তখন অংশগ্রহণকারী ভেন্যুজুড়ে কাজ করে।
উভয়েই IEEE 802.1X ব্যবহার করে, যা পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলের স্ট্যান্ডার্ড, তাই ব্রোকেন হওয়ার জন্য কোনো পোর্টাল নেই।
| অ্যাক্সেস পদ্ধতি | প্রথম ভিজিট | পুনরাগত ভিজিট | ওভার-দ্য-এয়ার এনক্রিপশন | প্রধান ত্রুটিজনক বিষয় | যা উপযোগী |
|---|---|---|---|---|---|
| ক্যাপটিভ পোর্টাল সহ ওপেন SSID | ভিজিটর লগইন পেজ পূরণ করেন | সেশন বা MAC ক্যাশের মেয়াদ শেষ হলে পুনরায় সাইন ইন করেন | কোনোটিই নয়, যদি না SSID এনহ্যান্সড ওপেন (OWE) ব্যবহার করে | প্রোব, ওয়াল্ড গার্ডেন, DNS, RADIUS | প্রতি ভিজিটে ফার্স্ট-পার্টি ডাটা ক্যাপচার করা ভেন্যুগুলি |
| শেয়ার করা প্রি- শেয়ার্ড কি (PSK) | ভিজিটর পাসওয়ার্ড টাইপ করেন | স্বয়ংক্রিয় | WPA2 বা WPA3-Personal | পাসওয়ার্ড শেয়ারিং, ভিজিটরের কোনো আইডেন্টিটি নেই | ডাটার কোনো লক্ষ্য ছাড়া ছোট ক্যাফে |
| Passpoint বা OpenRoaming | ভিজিটর একটি প্রোফাইল ইনস্টল করেন বা ফেডারেটেড আইডেন্টিটি ব্যবহার করেন | স্বয়ংক্রিয়, কোনো পোর্টাল নেই | WPA2 বা WPA3-Enterprise | প্রোফাইল প্রোভিশনিং, সার্টিফিকেট | হোটেল, বিমানবন্দর, রেল এবং ক্যাম্পাসে পুনরাগত ভিজিটরদের জন্য |
যেখানে Purple ফিট করে
Purple Guest WiFi একটি হার্ডওয়্যার-অ্যাগনোস্টিক ক্লাউড ওভারলে হিসেবে চলে, তাই আপনি নতুন হার্ডওয়্যার দিয়ে নয়, কনফিগারেশনে রিডাইরেক্ট ত্রুটিগুলি ঠিক করতে পারেন। Purple 90টিরও বেশি দেশে 80,000+ লাইভ ভেন্যুতে পরিষেবা দেয় এবং বছরে 500 মিলিয়ন ব্যবহারকারী এবং লগইন সমর্থন করে। প্ল্যাটফর্মটি 99.999% আপটাইমে চলে এবং এটি ISO 27001, Cyber Essentials এবং B Corp সার্টিফাইড। এটি GDPR এবং CCPA কমপ্লায়েন্টও।
একটি পোর্টাল ব্যর্থ হলে, তার কারণ সাধারণত প্রায় সব সময়ই স্থানীয় হয়: একটি প্রোভ রুল, একটি ওয়াল্ড গার্ডেন এন্ট্রি, একটি DHCP পুল অথবা একটি ফায়ারওয়াল রুল।
বিভিন্ন ক্ষেত্রে এই ধরণগুলির পুনরাবৃত্তি ঘটে:
- হোটেলগুলির চেক-ইন পিক টাইমে রিডাইরেক্টের ত্রুটি অনুভব হয়।
- রিটেল প্রাঙ্গণগুলিতে এস্টেট-জোড়া ফায়ারওয়াল পরিবর্তনের পর এই ত্রুটি অনুভূত হয়।
- ট্রেন এবং স্টেশনগুলিতে যাত্রীরা দলে দলে আসার কারণে DHCP চাপ বৃদ্ধি পায়।
- হেলথকেয়ার সাইটগুলিতে রোগী ও দর্শনার্থীদের জন্য এমন WiFi প্রয়োজন, যা ক্লিনিকাল কর্মীদের সাপোর্ট কলে না টেনেই সঠিকভাবে কাজ করে।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
Purple কি আমাদের পূর্বে থাকা অ্যাক্সেস পয়েন্টগুলির সাথে কাজ করে?
হ্যাঁ। Purple হল হার্ডওয়্যার-অ্যাগনোস্টিক এবং এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet-এর উপর একটি ক্লাউড ওভারলে হিসেবে রান করে। আপনি আপনার বিদ্যমান অ্যাক্সেস পয়েন্ট ও কন্ট্রোলারগুলি বজায় রাখতে পারেন। আপনি আপনার গেস্ট SSID-কে Purple-এর ক্যাপটিভ পোর্টাল-এর দিকে পয়েন্ট করুন, Purple-এর ইন্টিগ্রেশন গাইড থেকে ওয়াল্ড গার্ডেন এন্ট্রি ও RADIUS বিবরণ যোগ করুন, এবং তারপর টেস্ট করুন। এতে রিফ অ্যান্ড রিপ্লেসমেন্টের কোনো প্রয়োজন নেই।
গেস্ট WiFi কানেক্টেড থাকলেও ইন্টারনেটের অনুপস্থিতির সমস্যা সমাধান করতে আমাদের কি নতুন হার্ডওয়্যার দরকার?
না। প্রায় প্রতিটি ক্ষেত্রেই ত্রুটিটি কনফিগারেশন সংক্রান্ত: একটি ব্লকড প্রোভ, একটি ওয়াল্ড গার্ডেন গ্যাপ, প্রাক-অথেন্টিকেশন DNS, একটি শেষ হয়ে যাওয়া DHCP পুল বা একটি RADIUS ফায়ারওয়াল রুল। আপনি আপনার ইতিপূর্বে রান হওয়া কন্ট্রোলার, ফায়ারওয়াল বা DHCP সার্ভারেই এগুলির প্রতিটির সমাধান করতে পারেন। হার্ডওয়্যার শুধুমাত্র তখনই একটি সমস্যা হয়ে ওঠে যখন অ্যাক্সেস পয়েন্টের ডেনসিটি আপনার সর্বোচ্চ সংখ্যক ডিভাইসকে পরিষেবা দিতে পারে না, যা সাইট সার্ভেতে প্রদর্শিত হবে।
আমাদের গেস্ট WiFi-কে Purple-এ স্থানান্তর করতে কী করা প্রয়োজন?
Purple-এ স্থানান্তরিত হওয়া একটি কনফিগারেশন প্রজেক্ট, এটি ইনস্টলেশন প্রজেক্ট নয়। প্রতিটি কন্ট্রোলারে, আপনি গেস্ট SSID-কে Purple-এর এক্সটার্নাল পোর্টালে সেট করুন এবং ওয়াল্ড গার্ডেন ও RADIUS সেটিংস যোগ করুন। তারপর আপনি UDP 1812 এবং 1813-এর জন্য ফায়ারওয়াল রুলগুলি নিশ্চিত করুন। এরপরে, Purple-এ আপনার লগইন পেজ ও সম্মতির বিকল্পগুলি তৈরি করুন এবং iOS, Android এবং Windows-এ পরীক্ষা করুন। একাধিক সাইট যুক্ত এস্টেটগুলি কন্ট্রোলার সেটিংস টেমপ্লেট করতে পারে।
একটি ক্যাপটিভ পোর্টাল কি GDPR মেনে চলে?
হ্যাঁ, যদি সম্মতি অবহিত, নির্দিষ্ট এবং অবাধে প্রদত্ত হয়। GDPR-এর জন্য প্রতিটি উদ্দেশ্যে একটি পৃথক সম্মতিমূলক চয়েস প্রয়োজন, যেমন মার্কেটিং ইমেল, এবং পূর্ব-চিহ্নিত বক্সগুলি বাতিল করে। Purple-এর সচেতন-পছন্দের অপ্ট-ইনগুলি প্রতিটি পছন্দ আলাদাভাবে উপস্থাপন করে। Purple হল ISO 27001 সার্টিফাইড, এটি Cyber Essentials হোল্ড করে এবং এটি GDPR ও CCPA অনুবর্তী। এটি আপনার ডেটা প্রটেকশন অফিসারকে সেই স্ট্যান্ডার্ডগুলি প্রদান করে যা সম্পর্কে তারা জিজ্ঞাসা করবেন।
পুনঃপরিদর্শনকারী দর্শনার্থীরা কি লগইন পেজ এড়িয়ে যেতে পারেন?
হ্যাঁ। Passpoint এবং OpenRoaming একটি ডিভাইসকে একটি সংরক্ষিত প্রোফাইল বা ফেডারেটেড আইডেন্টিটি ব্যবহার করে স্বয়ংক্রিয়ভাবে যুক্ত হতে দেয়। উভয়ই WPA2 বা WPA3-Enterprise এনক্রিপশন সহ IEEE 802.1X অথেন্টিকেশন ব্যবহার করে, তাই বারবার পরিদর্শনের সময় ব্যর্থ হওয়ার মতো কোনো ক্যাপটিভ পোর্টাল রিডাইরেক্ট থাকে না। অনেক ভেন্যু উভয়ই পরিচালনা করে: প্রথমবার আসা দর্শনার্থীদের জন্য ও ডেটা ক্যাপচারের জন্য একটি ক্যাপটিভ পোর্টাল, এবং পুনঃপরিদর্শনকারী গেস্ট, যাত্রী ও শিক্ষার্থীদের জন্য OpenRoaming।
কখন লগইন ব্যর্থ হতে শুরু করছে তা আমরা কীভাবে জানব?
ভেন্যু অনুযায়ী লগইন ভলিউম দেখুন। Purple-এর WiFi অ্যানালিটিক্স প্রতিটি সাইটের জন্য লগইন রিপোর্ট করে, তাই কোনও নির্দিষ্ট স্থানে হঠাৎ লগইন সংখ্যা কমে গেলে তা সাধারণ প্যাটার্ন এবং আপনার অন্যান্য ভেন্যুর তুলনায় সহজেই চোখে পড়ে। এই ধরনের ড্রপ সাধারণত একটি সাম্প্রতিক পরিবর্তনের কারণে সৃষ্ট RADIUS, ওয়াল্ড গার্ডেন বা DHCP ত্রুটিকে নির্দেশ করে। ড্যাশবোর্ডে এটি সনাক্ত করা, ফ্রন্ট ডেস্কের অভিযোগ IT টিমের কাছে পৌঁছানো পর্যন্ত অপেক্ষা করার চেয়ে অনেক দ্রুত হয়।
আমাদের কি একটি ক্যাপটিভ পোর্টাল নাকি একটি শেয়ার করা WiFi পাসওয়ার্ড ব্যবহার করা উচিত?
আপনি যদি ফার্স্ট-পার্টি ডেটা এবং সম্মতি চান তবে ক্যাপটিভ পোর্টাল ব্যবহার করুন, আর আপনার যদি দুটির কোনওটিরই প্রয়োজন না থাকে তবেই শেয়ার করা পাসওয়ার্ড ব্যবহার করুন। একটি শেয়ার করা প্রি-শেয়ার্ড কী WPA2 বা WPA3-Personal এর মাধ্যমে ট্র্যাফিক এনক্রিপ্ট করে। তবে, কে কানেক্ট করেছে সে সম্পর্কে এটি আপনাকে কিছুই জানায় না এবং পাসওয়ার্ডও ছড়িয়ে পড়ে। একটি ক্যাপটিভ পোর্টাল সম্মতিযুক্ত ফার্স্ট-পার্টি ডেটা সংগ্রহ করে, এবং Passpoint বা OpenRoaming পুনরায় আসার ভিজিটের জন্য স্বয়ংক্রিয়, এনক্রিপ্ট করা অ্যাক্সেস যোগ করে।
মূল সংজ্ঞাসমূহ
ক্যাপটিভ পোর্টাল
ইন্টারনেট অ্যাক্সেস প্রদান করার আগে একটি গেটওয়ে (কন্ট্রোলার, ফায়ারওয়াল বা অ্যাক্সেস পয়েন্ট) দ্বারা উপস্থাপিত একটি ওয়েব পেজ। অপারেটিং সিস্টেমগুলি একটি সাধারণ HTTP প্রোব পাঠিয়ে এবং HTTP 302 রিডাইরেক্টকে পোর্টারের উপস্থিতি হিসাবে বিবেচনা করে এটি সনাক্ত করে।
গেস্ট WiFi কানেক্টেড কিন্তু নো ইন্টারনেট দেখানোর সময় এটি সেই স্তর যা ব্যর্থ হয়। আপনি গেস্ট SSID কে এক্সটার্নাল পোর্টাল URL-এর দিকে নির্দেশ করতে এবং আন-অথেন্টিকেটেড HTTP ট্র্যাফিককে সেটিতে রিডাইরেক্ট করতে কনফিগার করেন।
অপারেটিং সিস্টেম প্রোব
নেটওয়ার্কে যুক্ত হওয়ার সময় প্রতিটি প্ল্যাটফর্ম একটি সাধারণ HTTP রিকোয়েস্ট পাঠায়: iOS এবং macOS-এর জন্য captive.apple.com, Android-এর জন্য connectivitycheck.gstatic.com/generate_204, Windows-এর জন্য www.msftconnecttest.com/connecttest.txt এবং Firefox-এর জন্য detectportal.firefox.com, প্রতিটি অনলাইনে থাকলে একটি নির্দিষ্ট উত্তর প্রত্যাশা করে।
প্রি-অথেন্টিকেশন ACL বা একটি DNS ফিল্টার যদি প্রোবটিকে ফেলে দেয়, তবে ডিভাইসটি সিদ্ধান্ত নেয় যে কোনো ইন্টারনেট নেই এবং কখনোই পোর্টাল খোলে না। পোর্টাল কখনোই প্রদর্শিত না হওয়ার এটিই সবচেয়ে সাধারণ কারণ।
HSTS (HTTP স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি)
RFC 6797-এ সংজ্ঞায়িত, HSTS ব্রাউজারগুলিকে কেবল HTTPS-এর মাধ্যমে একটি ডোমেইনে পৌঁছানোর নির্দেশ দেয়। ব্রাউজারগুলি HSTS ডোমেনগুলির একটি প্রিলোড তালিকা সরবরাহ করে এবং ডিভাইস ছেড়ে যাওয়ার আগেই সেগুলির রিকোয়েস্ট আপগ্রেড করে।
একটি গেটওয়ে তার কাছে না থাকা সার্টিফিকেট ছাড়া কোনো HSTS ডোমেইনে একটি HTTPS রিকোয়েস্ট রিডাইরেক্ট করতে পারে না, তাই ভিজিটর একটি গুরুতর সুরক্ষা সতর্কবার্তা দেখতে পান। কেবল HTTP প্রোবগুলি রিডাইরেক্ট করুন এবং কর্মীদের সংক্ষিপ্ত নির্দেশ দিন যাতে তারা কখনোই ভিজিটরদের google.com-এ না পাঠান।
ওয়াল্ড গার্ডেন
প্রি-অথেন্টিকেশন স্টেট-এ গেটওয়ের প্রি-অথেন্টিকেশন অ্যাক্সেস কন্ট্রোল লিস্টের মাধ্যমে একটি ডিভাইস যেসব ডোমেইন এবং IP অ্যাড্রেসে পৌঁছাতে পারে, তার অ্যালাউ লিস্ট।
Microsoft Entra ID, Okta বা Google Workspace-এর মতো আইডেন্টিটি প্রোভাইডার, কনটেন্ট ডেলিভারি নেটওয়ার্ক বা Purple এন্ডপয়েন্টের এন্ট্রি না থাকলে পৃষ্ঠা আংশিক লোড হয় এবং সোশ্যাল লগইন নিঃশব্দে ব্যর্থ হয়।
RADIUS
রিমোট অথেন্টিকেশন ডায়াল-ইন ইউজার সার্ভিস, যা UDP 1812-এ অথেন্টিকেশনের জন্য RFC 2865 এবং UDP 1813-এ অ্যাকাউন্টিংয়ের জন্য RFC 2866-এ সংজ্ঞায়িত। সার্ভার প্রতিটি Access-Request-এর উত্তর Access-Accept বা Access-Reject দিয়ে দেয়।
RADIUS আপনার গেটওয়েতে লগইনের সিদ্ধান্ত বহনে সাহায্য করে। অমিল থাকা শেয়ার্ড সিক্রেট, UDP 1812 বা 1813 ব্লক করা ফায়ারওয়াল, অথবা ভুল সার্ভার অ্যাড্রেসের কারণে সফলভাবে লগইন করার পরেও দর্শকরা অফলাইনে থেকে যান।
অ্যাকাউন্টিং-রিকোয়েস্ট (স্টার্ট)
RFC 2866-এ সংজ্ঞায়িত একটি RADIUS অ্যাকাউন্টিং মেসেজ, যা কোনো সেশন শুরু হওয়ার সময় UDP 1813-এ পাঠানো হয় এবং এতে Start-এর মতো স্ট্যাটাস টাইপ থাকে।
লগইনের পর কন্ট্রোলার লগে এর উপস্থিতি নিশ্চিত করে যে গেটওয়ে Access-Accept প্রয়োগ করেছে। লগইনের পর কোনো অ্যাকাউন্টিং রেকর্ড না থাকার অর্থ হলো RADIUS পাথটি ক্ষতিগ্রস্ত।
NCSI (নেটওয়ার্ক কানেক্টিভিটি স্ট্যাটাস ইন্ডিকেটর)
Windows কানেক্টিভিটি চেক যা www.msftconnecttest.com-এ একটি HTTP প্রোব পাঠায় এবং DNS চেক হিসেবে dns.msftncsi.com রিসলভ করে, যেখানে Microsoft Connect Test টেক্সটটি প্রত্যাশিত।
একটি Windows ল্যাপটপ HTTP কাজ করলেও প্রি-অথেন্টিকেশন DNS ক্ষতিগ্রস্ত থাকলে ইন্টারনেট নেই বলে রিপোর্ট করতে পারে, এবং লগইনের পরে অনবরত 'No internet' দেখানোর অর্থ হলো গেটওয়ে এখনও প্রোবটিকে রিডাইরেক্ট করছে।
ক্যাপটিভ পোর্টাল API (DHCP option 114)
RFC 8910-এ সংজ্ঞায়িত, DHCP option 114 নেটওয়ার্ককে সরাসরি ডিভাইসের কাছে তার ক্যাপটিভ পোর্টাল URI বিজ্ঞাপন করতে দেয়, যাতে ডিভাইসটিকে প্রোব ইন্টারসেপ্ট করার ওপর নির্ভর করতে না হয়।
সাম্প্রতিক iOS এবং macOS রিলিজ এটিকে সাপোর্ট করে, যা রিডাইরেকশনের ওপর নির্ভরতা এবং এর সাথে সম্পর্কিত ত্রুটিগুলি কমায়।
প্রাইভেট DNS (DNS ওভার TLS)
একটি Android সেটিং, যেখানে নির্দিষ্ট হোস্টনেম সেট করা থাকলে সাধারণ DNS-এর পরিবর্তে পোর্ট 853-এ TLS দিয়ে এনক্রিপ্ট করা DNS কোয়েরি পাঠানো হয়। স্বয়ংক্রিয় মোডে এটি সাধারণ DNS-এ ফিরে যায়।
কঠোর Private DNS হোস্টনেম থাকা দর্শকরা দেখতে পান 'Private DNS server cannot be accessed'। আপনি হয় অথেন্টিকেশনের আগে পোর্ট 853 অ্যালাউ করুন অথবা দর্শককে স্বয়ংক্রিয় মোডে সুইচ করতে বলুন।
Passpoint এবং OpenRoaming
Passpoint হলো স্টোর করা প্রোফাইলের সাথে স্বয়ংক্রিয়ভাবে নেটওয়ার্কে যুক্ত হওয়ার জন্য Hotspot 2.0 স্পেসিফিকেশনের ওপর তৈরি ইন্ডাস্ট্রি সার্টিফিকেশন। Wireless Broadband Alliance দ্বারা চালিত OpenRoaming, আইডেন্টিটি প্রোভাইডারদের সংযুক্ত করে। উভয়ই IEEE 802.1X পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল এবং WPA2 বা WPA3-Enterprise এনক্রিপশন দিয়ে অথেন্টিকেট করে।
এগুলি বারবার আসা দর্শকদের ক্যাপটিভ পোর্টাল থেকে সম্পূর্ণরূপে সরিয়ে নেয়, তাই বারবার ভিজিটের ক্ষেত্রে ব্যর্থ হওয়ার মতো কোনো রিডাইরেক্ট থাকে না, যদিও পোর্টালটি এখনও প্রথম ভিজিট এবং ডেটা ক্যাপচার পরিচালনা করে।
সমাধানকৃত উদাহরণসমূহ
১,৫০০ আসন বিশিষ্ট একটি কনফারেন্স সেন্টারে আট ঘণ্টার DHCP লিজ সহ একটি একক /24 সাবনেটে অংশগ্রহণকারীদের WiFi চালানো হচ্ছিল। সকালের সেশনগুলি ঠিকঠাক চললেও, দুপুরের খাবারের পর নতুন আসা ব্যবহারকারীরা কানেক্টেড কিন্তু নো ইন্টারনেট সমস্যাটি দেখতে পান এবং হেল্প ডেস্কে থাকা কর্মীরা কন্ট্রোলারটি দুবার রিস্টার্ট করেন।
ডায়াগনোসিসের ১ম ধাপে দেখা গেছে যে নতুন ডিভাইসগুলি 169.254.x.x লিঙ্ক-লোকাল ঠিকানা ধারণ করে আছে, যা পোর্টালের দিকে নয়, বরং DHCP-র দিকে নির্দেশ করে। একটি /24 সাবনেট ২৫৪টি ব্যবহারযোগ্য ঠিকানা প্রদান করে এবং আট ঘণ্টার লিজের কারণে সকালের প্রতিটি ঠিকানা সংরক্ষিত ছিল, ফলে পুল খালি হয়ে যায়। টিমটি অংশগ্রহণকারীদের VLAN কে একটি /21-এ স্থানান্তরিত করে এবং লিজ কমিয়ে ৩০ মিনিট করে দেয়। ব্যবহারযোগ্য ঠিকানা ২৫৪ থেকে বেড়ে ২,০৪৬-এ পৌঁছেছে, যা আগের ক্ষমতার প্রায় আট গুণ, এবং চলে যাওয়া স্থান ছেড়ে যাওয়া ব্যবহারকারীদের ঠিকানাগুলি এখন ৩০ মিনিটের মধ্যে পুলে ফিরে আসে। এই সমাধানের জন্য কেবল একটি চেঞ্জ উইন্ডো লেগেছে এবং কোনো নতুন হার্ডওয়্যারের প্রয়োজন হয়নি।
একটি লগইন পেজ পুনরায় ডিজাইন করার পরে, একটি ২০০ ঘরের হোটেলের Android গেস্টরা ফ্রন্ট ডেস্কে এসে অভিযোগ জানাতে থাকেন। পোর্টালটি দৃশ্যমান হলেও, Google সাইন-ইন বোতামটি কোনো কাজ করছিল না।
IT ম্যানেজার একটি iPhone, একটি Android ফোন এবং একটি Windows ল্যাপটপে পুরো প্রক্রিয়াটি পরীক্ষা করেন। ল্যাপটপের ব্রাউজার ডেভেলপার টুলস একটি ফন্ট ডেলিভারি নেটওয়ার্ক এবং Google-এর সাইন-ইন ডোমেইনে ব্লক করা রিকোয়েস্ট দেখায়, যা দুটিই পুনরায় ডিজাইনের সময় যুক্ত করা হয়েছিল। যেহেতু পোর্টাল নিজেই লোড হচ্ছিল, তাই ত্রুটিটি প্রোব রিডাইরেক্টে নয়, ওয়াল্ড গার্ডেনে অবস্থান করছিল। টিম ওয়াল্ড গার্ডেনে দুটি ডোমেইন যোগ করেছে। দুটি ওয়াল্ড গার্ডেন এন্ট্রি দিয়ে এবং কোনো হার্ডওয়্যার পরিবর্তন ছাড়াই প্রথম পুর্নপরীক্ষাতেই তিনটি টেস্ট ডিভাইসে Google সাইন-ইন সম্পন্ন হয়েছে।
একটি রিটেইলার সপ্তাহান্তে ৪০টি দোকানে ফায়ারওয়াল পরিবর্তন করেছে। সোমবারে, নতুন সিস্টেম পাওয়া প্রতিটি দোকানের ক্রেতারা লগইন ফর্মটি পূরণ করলেও অফলাইনে থেকে যান, যেখানে যেসব দোকানে পরিবর্তন করা হয়নি সেগুলি স্বাভাবিকভাবে কাজ করছিল।
ডায়াগনোসিসের ৫ নম্বর ধাপে কন্ট্রোলার RADIUS লগগুলি পরীক্ষা করে নতুন সিস্টেম পাওয়া দোকানগুলি থেকে কোনো অ্যাকাউন্টিং রেকর্ড পাওয়া যায়নি, যার অর্থ গেটওয়ে কখনও Access-Accept গ্রহণ করেনি। নতুন ফায়ারওয়াল টেমপ্লেটটি ডিফল্টভাবে আউটবাউন্ড UDP নিষিদ্ধ করেছিল, যা ১৮১২ এবং ১৮১৩ নম্বর পোর্ট দুটি ব্লক করেছিল। টিম টেমপ্লেটে স্পষ্ট আউটবাউন্ড রুল যোগ করেছে এবং তা ৪০টি দোকানেই পুশ করেছে, যার ফলে প্রতিটি দোকান থেকেই পুনরায় অ্যাকাউন্টিং রেকর্ড দৃশ্যমান হতে শুরু করেছে। যেহেতু কেবল নতুন সিস্টেম পাওয়া দোকানগুলিতে সমস্যা হয়েছিল, তাই এটি সরাসরি ফায়ারওয়াল টেমপ্লেটের ত্রুটির দিকে নির্দেশ করে এবং WiFi-এর থেকে নজর সরিয়ে নেয়।
অনুশীলনী প্রশ্নসমূহ
Q1. একটি ৫,০০০ আসন বিশিষ্ট ভেন্যুতে একটি বড় কনফারেন্স চলাকালীন, IT টিম রিপোর্ট পায় যে শত শত উপস্থিত সদস্য গেস্ট WiFi পোর্টাল অ্যাক্সেস করতে পারছেন না। অ্যাক্সেস পয়েন্টগুলি স্বাভাবিক অ্যাসোসিয়েশন সংখ্যা দেখাচ্ছে। ইভেন্ট শুরু হওয়ার ৪৫ মিনিট পর এই সমস্যাটি শুরু হয়। এর সবচেয়ে সম্ভাব্য কারণ কী এবং তাৎক্ষণিক সমাধান কী?
ইঙ্গিত: সমস্যাটি ইভেন্ট চলাকালীন শুরু হয়েছিল, শুরু হওয়ার সাথে সাথে নয়। আরও ডিভাইস যুক্ত হওয়ার সাথে সাথে কোন রিসোর্সটি সীমিত হয়ে পড়ে তা বিবেচনা করুন।
মডেল উত্তর দেখুন
সবচেয়ে সম্ভাব্য কারণ হলো DHCP পুল শেষ হয়ে যাওয়া। উপস্থিত সদস্যরা আসার সাথে সাথে SSID-এর সাথে যুক্ত হওয়ার ফলে DHCP পুলটি ভরে যায়। নতুন ডিভাইসগুলি অ্যাক্সেস পয়েন্টের সাথে যুক্ত হয় কিন্তু IP অ্যাড্রেস পেতে পারে না, তাই তারা কখনই ক্যাপটিভ পোর্টাল ট্র্রিগার করার জন্য প্রয়োজনীয় HTTP প্রোব পাঠায় না। তাৎক্ষণিক সমাধান হলো DHCP লিজের সময় কমিয়ে ১৫ মিনিট করা (প্রস্থান করা ডিভাইসগুলি থেকে দ্রুত অ্যাড্রেসগুলি পুনরায় ফেরত পাওয়া) এবং সম্ভব হলে একটি দ্বিতীয় সাবনেট যোগ করে পুলটি সম্প্রসারিত করা। দীর্ঘমেয়াদী সমাধান হলো পরবর্তী ইভেন্টে গড়ের ওপর ভিত্তি না করে সর্বাধিক সমসাময়িক ডিভাইসের সংখ্যার ওপর ভিত্তি করে DHCP পুলের আকার নির্ধারণ করা।
Q2. আপনি একটি রিটেল চেইনে Ubiquiti UniFi অ্যাক্সেস পয়েন্টগুলিতে Purple ডিপ্লয় করেছেন। স্প্ল্যাশ পেজটি সমস্ত ডিভাইসে সঠিকভাবে লোড হচ্ছে। গেস্টরা ইমেল ক্যাপচার ফর্ম পূরণ করছেন এবং একটি সফল মেসেজ দেখছেন। কিন্তু তারা ব্রাউজ করার চেষ্টা করলে ইন্টারনেট অ্যাক্সেস পাচ্ছেন না। Purple ড্যাশবোর্ড লগইন সফল হিসাবে দেখাচ্ছে। আপনি প্রথমে কী পরীক্ষা করবেন?
ইঙ্গিত: ক্লাউড প্ল্যাটফর্ম অথেন্টিকেশন রেকর্ড করেছে। ত্রুটিটি স্থানীয় এনফোর্সমেন্ট স্টেপে রয়েছে।
মডেল উত্তর দেখুন
কারণ Purple-এর ড্যাশবোর্ড সফল লগইন দেখাচ্ছে, ক্লাউড অথেন্টিকেশন ধাপটি সঠিকভাবে সম্পন্ন হয়েছে। সমস্যাটি RADIUS অথরাইজেশন ধাপে রয়েছে - UniFi কন্ট্রোলার Purple-এর RADIUS সার্ভার থেকে Access-Accept মেসেজটি গ্রহণ করছে না বা সেই অনুযায়ী কাজ করছে না। এই ক্রমে পরীক্ষা করুন: (1) UniFi কন্ট্রোলারের RADIUS শেয়ার্ড সিক্রেটটি Purple-এর ড্যাশবোর্ডের সিক্রেটের সাথে হুবহু মিলছে কিনা; (2) কন্ট্রোলার থেকে Purple-এর RADIUS সার্ভার IP অ্যাড্রেসগুলিতে 1812 এবং 1813 পোর্টগুলির আউটবাউন্ড UDP অনুমোদিত কিনা; (3) UniFi কন্ট্রোলারে কনফিগার করা RADIUS সার্ভার IP অ্যাড্রেসগুলি সাম্প্রতিক কিনা (Purple সেগুলি আপডেট করে থাকতে পারে)। কন্ট্রোলারে একটি প্যাকেট ক্যাপচার নিশ্চিত করবে যে Access-Accept মেসেজটি আসছে কিনা।
Q3. একটি হোটেলের IT ম্যানেজার রিপোর্ট করেছেন যে তাদের ডিভাইসে ভিপিএন ব্যবহার করা গেস্টরা ক্যাপটিভ পোর্টালে একেবারেই অ্যাক্সেস করতে পারছেন না। ভিপিএন ছাড়া গেস্টরা স্বাভাবিকভাবে কানেক্ট করছেন। হোটেলটি Cisco Meraki MX অ্যাপ্লায়েন্স ব্যবহার করে। ভিপিএন ব্যবহারকারীদের সুবিধা দেওয়ার জন্য IT টিমের কি ক্যাপটিভ পোর্টাল কনফিগারেশন পরিবর্তন করা উচিত?
ইঙ্গিত: ক্যাপটিভ পোর্টাল ডিভাইসের নেটওয়ার্ক ট্র্যাফিক ইন্টারসেপ্ট করার আগে ভিপিএন ট্র্যাফিকের ওপর কী প্রভাব ফেলে তা বিবেচনা করুন।
মডেল উত্তর দেখুন
না - ক্যাপটিভ পোর্টাল কনফিগারেশন পরিবর্তন করার প্রয়োজন নেই। একটি ভিপিএন ক্লায়েন্ট HTTP কানেক্টিভিটি প্রোব সহ ডিভাইসের সমস্ত ট্র্যাফিক ডিভাইস ত্যাগ করার আগেই এনক্রিপ্ট করে। গেটওয়ে এনক্রিপ্ট করা ভিপিএন ট্র্যাফিক ইন্টারসেপ্ট করতে পারে না, তাই এটি কখনোই 302 রিডাইরেক্ট ইস্যু করে না। গেস্টকে অবশ্যই তাদের ভিপিএন ডিসেবল করতে হবে, ক্যাপটিভ পোর্টাল অথেন্টিকেশন সম্পন্ন করতে হবে এবং তারপর ভিপিএন পুনরায় এনেবল করতে হবে। এটি ক্যাপটিভ পোর্টাল এবং ভিপিএন-এর একটি মৌলিক আর্কিটেকচারাল সীমাবদ্ধতা, কোনো কনফিগারেশন ত্রুটি নয়। IT টিমের উচিত গেস্ট WiFi নির্দেশাবলীতে একটি নোট যোগ করা, যাতে ভিপিএন ব্যবহারকারীদের কানেক্ট করার আগে তাদের ভিপিএন ডিসেবল করার পরামর্শ দেওয়া হয়।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
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.
সূত্রসমূহ
- RFC 6797: HTTP Strict Transport Security (HSTS)
- RFC 2865: Remote Authentication Dial In User Service (RADIUS)
- RFC 2866: RADIUS Accounting
- RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements
- Wireless Broadband Alliance: OpenRoaming
- Regulation (EU) 2016/679 (GDPR)
- PCI Security Standards Council: PCI DSS
এই সিরিজে পড়া চালিয়ে যান
Ruckus captive portal ট্রাবলশুটিং: WISPr রিডাইরেক্ট, hotspot এবং walled garden চেকলিস্ট
আপনি অতিথিদের দেওয়া রিপোর্টের লক্ষণ থেকে একটি ত্রুটিপূর্ণ Ruckus captive portal নির্ণয় করতে পারবেন এবং তারপরে একটি নির্দিষ্ট ক্রমে সেটি সমাধান করতে পারবেন। এই ক্রমটির মধ্যে রয়েছে hotspot (WISPr) লগঅন URL, walled garden, northbound portal interface পাসওয়ার্ড, RADIUS authentication এবং accounting, এবং HTTPS রিডাইরেক্ট সার্টিফিকেট। এই পরীক্ষাগুলি SmartZone, Ruckus One এবং Unleashed-এ প্রযোজ্য।
Ubiquiti UniFi captive portal ট্রাবলশুটিং: এক্সটার্নাল পোর্টাল, hotspot এবং walled garden চেকলিস্ট
আপনার Ubiquiti UniFi captive portal কেন কাজ করছে না তা খুঁজে বের করতে এবং এটি সমাধান করতে এই চেকলিস্টটি ব্যবহার করুন। আপনি লক্ষণটিকে ছয়টি কারণের একটির সাথে মেলাবেন, দুটি দ্রুত পরীক্ষা চালাবেন এবং external portal server, pre-authorisation access, guest subnet restrictions, HTTPS redirects, controller reachability বা ক্লায়েন্ট সেটিংস সংশোধন করবেন।
HPE Aruba captive portal ট্রাবলশুটিং: রিডাইরেক্ট, সার্টিফিকেট এবং ওয়াল্ড গার্ডেন চেকলিস্ট
আপনার দেখা লক্ষণ থেকে একটি ব্যর্থ HPE Aruba captive portal নির্ণয় করতে এই চেকলিস্টটি ব্যবহার করুন: কোনো redirect নেই, একটি certificate সতর্কতা বা এমন কোনো অতিথি যে কখনই রিলিজ হয় না। তারপরে আপনি ত্রুটিটি DNS, DHCP, walled garden, redirect URL, certificate বা RADIUS-এ সনাক্ত করতে পারেন। অবশেষে, Instant APs, Aruba Central বা একটি mobility controller-এ সমাধান প্রয়োগ করুন।
আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?
আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।