মূল কন্টেন্টে যান
বাংলা

Public WiFi ট্রাবলশুটিং: 'Connected, No Internet' এবং স্প্ল্যাশ পেজ রিডাইরেকশন ব্যর্থতা সমাধান করা

এই নির্ভরযোগ্য টেকনিক্যাল রেফারেন্স নির্দেশিকাটি captive portal সনাক্তকরণের অন্তর্নিহিত মেকানিজম ব্যাখ্যা করে এবং গেস্ট WiFi সংযোগে বাধা সৃষ্টিকারী ছয়টি প্রাথমিক ব্যর্থতার মোড বিস্তারিতভাবে আলোচনা করে। এটি IT ম্যানেজার এবং নেটওয়ার্ক আর্কিটেক্টদের HTTP রিডাইরেক্ট সমস্যা, DNS দ্বন্দ্ব এবং MAC র্যান্ডমাইজেশন চ্যালেঞ্জগুলি সমাধান করার জন্য একটি ব্যবহারিক ট্রাবলশুটিং ফ্রেমওয়ার্ক প্রদান করে।

লিখেছেন Tom Hackettপ্রকাশিত হালনাগাদ করা হয়েছে
📖 6 মিনিট পাঠ1,343 শব্দ2 সমাধানকৃত উদাহরণ3 অনুশীলনী প্রশ্ন8 মূল সংজ্ঞা

Video overview

এই গাইডটি শুনুন

পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
Purple-এর এই টেকনিক্যাল ব্রিফিংয়ে আপনাকে স্বাগত। আজ আমরা এন্টারপ্রাইজ ওয়্যারলেস নেটওয়ার্কিংয়ের সবচেয়ে দীর্ঘস্থায়ী এবং সবচেয়ে ভুল বোঝাবুঝি সমস্যাগুলির একটি সমাধান করছি: গেস্ট WiFi captive portal যা কোনোভাবেই লোড হতে চায় না। আপনি নিজেই এই পরিস্থিতির সম্মুখীন হয়েছেন। কোনো গেস্ট আপনার হোটেল, রিটেল স্টোর, স্টেডিয়াম বা কনফারেন্স সেন্টারে আসলেন। তারা WiFi নেটওয়ার্কে যুক্ত হলেন। কিন্তু কিছুই হলো না। কোনো লগইন পেজ নেই। কোনো ইন্টারনেট নেই। কেবল একটি স্পিনিং আইকন এবং ক্রমবর্ধমান হতাশা। ভেন্যু অপারেশন ডিরেক্টর এবং IT ম্যানেজারদের জন্য, সেই মুহূর্তটি কেবল একটি ছোটখাটো অসুবিধা নয়। এটি আপনার গেস্ট এক্সপেরিয়েন্সের একটি সরাসরি ব্যর্থতা, ফ্রন্ট-অফ-হাউস সাপোর্ট কলের সংখ্যা বৃদ্ধি এবং সেই ফার্স্ট-পার্টি ডেটা সংগ্রহ করার একটি সুযোগ হাতছাড়া হওয়া যা আপনার ওয়্যারলেস ইনফ্রাস্ট্রাকচার ইনভেস্টমেন্টকে যুক্তিযুক্ত করে। এই ব্রিফিংয়ে, আমরা এর ভেতরের কার্যপদ্ধতি বিশ্লেষণ করব। অপারেটিং সিস্টেম স্তরে captive portal ডিটেকশন কীভাবে কাজ করে তা আমরা বিস্তারিত ব্যাখ্যা করব, বেশিরভাগ কানেকশন ব্যর্থতার জন্য দায়ী ছয়টি প্রধান কারণ চিহ্নিত করব এবং আপনাকে একটি ব্যবহারিক ও কার্যকর ট্রাবলশুটিং ফ্রেমওয়ার্ক প্রদান করব যা আপনি আজই আপনার IT টিমকে হস্তান্তর করতে পারবেন। আসুন মেকানিক্স দিয়ে শুরু করা যাক। বেশিরভাগ মানুষ captive portal-কে কেবল একটি লগইন পেজ হিসেবে ভাবেন। আসলে এটি একটি নেটওয়ার্ক-স্তরের ট্রাফিক ইন্টারসেপশন মেকানিজম, এবং কোনো সমস্যা দেখা দিলে এই পার্থক্যটি অত্যন্ত গুরুত্বপূর্ণ হয়ে ওঠে। এখানে প্রক্রিয়াটি দেওয়া হলো। একজন গেস্টের ডিভাইস আপনার গেস্ট SSID-তে যুক্ত হয় এবং DHCP-এর মাধ্যমে একটি IP অ্যাড্রেস লাভ করে। সেই মুহূর্তে, অপারেটিং সিস্টেম ব্যবহারকারীর ব্রাউজার খোলার জন্য অপেক্ষা করে না। ব্যাকগ্রাউন্ডে, একটি সিস্টেম সার্ভিস অবিলম্বে একটি ভেন্ডর-নিয়ন্ত্রিত প্রোব URL-এ একটি আনএনক্রিপ্টেড HTTP GET রিকোয়েস্ট পাঠায়। Apple ডিভাইসগুলি captive.apple.com-এ কোয়েরি পাঠায়। Android ডিভাইসগুলি connectivitycheck.gstatic.com-এ কোয়েরি পাঠায়। Windows ডিভাইসগুলি msftconnecttest.com-এ কোয়েরি পাঠায়। Firefox-এর নিজস্ব প্রোব রয়েছে detectportal.firefox.com-এ। যদি নেটওয়ার্কটিতে ওপেন ইন্টারনেট অ্যাক্সেস থাকে, তবে এই প্রোবগুলি তাদের প্রত্যাশিত রেসপন্স ফেরত পায় এবং অপারেটিং সিস্টেম সিদ্ধান্ত নেয় যে সবকিছু ঠিক আছে। কিন্তু একটি গেস্ট নেটওয়ার্কে, আপনার ওয়্যারলেস গেটওয়ে বা কন্ট্রোলার সেই HTTP প্রোবটি ইন্টারনেটে পৌঁছানোর আগেই ইন্টারসেপ্ট বা বাধা দেয়। প্রত্যাশিত রেসপন্সের পরিবর্তে, গেটওয়েটি আপনার captive portal স্প্ল্যাশ পেজ নির্দেশ করে একটি HTTP 307 রিডাইরেক্ট ফেরত পাঠায়। অপারেটিং সিস্টেম এই অপ্রত্যাশিত রিডাইরেক্টটি ডিটেক্ট করে বুঝতে পারে যে এটি একটি captive portal-এর অধীনে রয়েছে এবং লগইন পেজটি দেখানোর জন্য একটি স্যান্ডবক্সড ব্রাউজার উইন্ডো খোলে - যাকে প্রায়শই Captive Network Assistant বলা হয়। এটি হলো স্বাভাবিক এবং সফল প্রক্রিয়া। এবার আসুন আলোচনা করা যাক সেই ছয়টি কারণ নিয়ে যার ফলে এটি ব্যাহত হয়। মূল কারণ নম্বর এক: DHCP পুল নিঃশেষ হয়ে যাওয়া। উচ্চ-ঘনত্বের ইভেন্টগুলিতে এটি একটি নীরব ঘাতক। আপনি যদি একটি স্ট্যান্ডার্ড স্ল্যাশ-২৪ সাবনেটে দুই হাজার উপস্থিতির একটি কনফারেন্স পরিচালনা করেন, তবে আপনার কাছে ২৫৪টি ব্যবহারযোগ্য IP অ্যাড্রেস রয়েছে। আপনার DHCP লিজ টাইম যদি ডিফল্ট ২৪ ঘণ্টা সেট করা থাকে, তবে দরজা খোলার কয়েক মিনিটের মধ্যেই আপনার সেই পুলটি নিঃশেষ হয়ে যাবে। এর পরের প্রতিটি সংযোগের চেষ্টা Captive Portal সিকোয়েন্স শুরু হওয়ার আগেই ব্যর্থ হবে। এর সমাধানটি সহজ: উচ্চ-টার্নওভার পরিবেশের জন্য গেস্ট DHCP লিজ টাইম ১৫ থেকে ৩০ মিনিটের মধ্যে সেট করুন এবং শুধুমাত্র মোট সংখ্যার ওপর ভিত্তি করে নয়, পিক কনকারেন্ট ব্যবহারকারীদের জন্য আপনার সাবনেটের আকার সঠিকভাবে নির্ধারণ করুন। মূল কারণ নম্বর দুই: DNS ইন্টারসেপশন ব্যর্থতা। Captive Portal রিডাইরেকশন মূলত গেটওয়ের HTTP প্রোব ইন্টারসেপ্ট করার ক্ষমতার ওপর নির্ভর করে। কিন্তু প্রোবের জন্য প্রথমে একটি DNS লুকআপের প্রয়োজন হয়। আপনার DNS কনফিগারেশন যদি প্রি-অথেন্টিকেটেড ক্লায়েন্টদের এক্সটার্নাল ডোমেন নেম রেজোলিউশন করার অনুমতি না দেয়, তবে প্রোবটি কখনোই ফায়ার হবে না। আপনার ফায়ারওয়াল পলিসি যেন স্পষ্টভাবে আনঅথেন্টিকেটেড ক্লায়েন্টদের থেকে DNS কোয়েরি করার অনুমতি দেয় তা নিশ্চিত করুন, এবং একটি টেস্ট ডিভাইসের বিরুদ্ধে প্যাকেট ক্যাপচার রান করে আপনার DNS ইন্টারসেপশন কাজ করছে কিনা তা যাচাই করুন। মূল কারণ নম্বর তিন: অসম্পূর্ণ ওয়াল্ড গার্ডেন (walled garden)। ওয়াল্ড গার্ডেন - যাকে প্রি-অথেনটিকেশন অ্যাক্সেস কন্ট্রোল লিস্টও বলা হয় - নির্ধারণ করে যে আনঅথেন্টিকেটেড গেস্টরা কোন এক্সটার্নাল ডোমেনগুলিতে পৌঁছাতে পারবে। আপনার পোর্টাল স্প্ল্যাশ পেজ যদি এমন কোনো CDN থেকে অ্যাসেট লোড করে যা ওয়াল্ড গার্ডেনে অন্তর্ভুক্ত নয়, তবে পেজটি একটি ফাঁকা স্ক্রিন হিসেবে প্রদর্শিত হবে। আপনি যদি Google, Apple, বা Facebook এর মাধ্যমে সোশ্যাল লগইন অফার করেন, তবে সেই প্রোভাইডারদের ব্যবহৃত প্রতিটি OAuth ডোমেন অবশ্যই হোয়াইটলিস্টেড থাকতে হবে। এবং এখানে একটি গুরুত্বপূর্ণ বিষয় রয়েছে: সোশ্যাল আইডেন্টিটি প্রোভাইডাররা নিয়মিত তাদের CDN IP রেঞ্জ এবং অথেনটিকেশন ডোমেন আপডেট করে। ছয় মাস আগে যে ওয়াল্ড গার্ডেনটি নিখুঁতভাবে কাজ করছিল, সেটি আজ নীরবে অকেজো হয়ে যেতে পারে। প্রতি ত্রৈমাসিকে ওয়াল্ড গার্ডেন অডিট করার শিডিউল তৈরি করুন এবং যেখানে আপনার হার্ডওয়্যার এটি সাপোর্ট করে সেখানে ওয়াইল্ডকার্ড ডোমেন স্নুপিং ব্যবহার করুন। Cisco Meraki, HPE Aruba, Ruckus, এবং Juniper Mist-এ এটি নেটিভলি উপলব্ধ রয়েছে। মূল কারণ নম্বর চার: HSTS দ্বারা রিডাইরেক্ট ব্লক হওয়া। HTTP Strict Transport Security, বা HSTS হলো একটি ব্রাউজার সিকিউরিটি পলিসি যা নির্দিষ্ট ডোমেনে শুধুমাত্র HTTPS-এর মাধ্যমে সংযোগ স্থাপন করতে বাধ্য করে। যদি কোনো গেস্টের ডিভাইস একটি HSTS-প্রিলোডেড ডোমেনের সাথে যোগাযোগ করার চেষ্টা করে - যার মধ্যে কার্যত প্রতিটি বড় ওয়েবসাইট অন্তর্ভুক্ত রয়েছে - এবং আপনার গেটওয়ে যদি পোর্টালে রিডাইরেক্ট করার জন্য সেই HTTPS রিকোয়েস্টটি ইন্টারসেপ্ট করার চেষ্টা করে, তবে ব্রাউজারটি একটি সার্টিফিকেট মিসম্যাচ সনাক্ত করবে। এটি একটি বাইপাস-অযোগ্য সিকিউরিটি ওয়ার্নিং প্রদর্শন করে এবং রিডাইরেক্টটিকে সম্পূর্ণরূপে ব্লক করে দেয়। সঠিক সমাধান হলো কখনোই HTTPS ইন্টারসেপশন করার চেষ্টা না করা। আপনার গেটওয়ের শুধুমাত্র আনএনক্রিপ্টেড HTTP ক্যানারি প্রোবগুলিকে রিডাইরেক্ট করা উচিত। এর দীর্ঘমেয়াদী স্ট্যান্ডার্ড-ভিত্তিক সমাধান হলো RFC 8910, যা DHCP Option 114 সংজ্ঞায়িত করে। এই অপশনটি আপনার DHCP সার্ভারকে সরাসরি ক্লায়েন্ট ডিভাইসে Captive Portal URL প্রচার করার অনুমতি দেয়, যার ফলে HTTP রিডাইরেকশনের কোনো প্রয়োজনই থাকে না। iOS 14 এবং Android 11 এবং তার পরবর্তী সংস্করণগুলি এটিকে নেটিভলি সাপোর্ট করে।মূল কারণ নম্বর পাঁচ: গেস্ট ডিভাইসে সক্রিয় VPN। একটি VPN ডিভাইস থেকে আসা সমস্ত ট্র্যাফিক এনক্রিপ্ট করে এবং আপনার গেটওয়েতে পৌঁছানোর আগেই এটিকে একটি বাহ্যিক টানেলের মাধ্যমে রাউট করে। আপনার গেটওয়ে কখনই HTTP প্রোব দেখতে পায় না। Captive Portal সনাক্তকরণ সিকোয়েন্সটি কখনই ট্রিগার হয় না। গেস্ট কোনো লগইন পেজ এবং ইন্টারনেট দেখতে পান না। গেস্টের জন্য সমাধানটি সহজ: VPN নিষ্ক্রিয় করুন, পোর্টালের সাথে সংযোগ করুন, তারপর আবার VPN সক্ষম করুন। আপনার ফ্রন্ট-অফ-হাউস কর্মীদের জন্য, কোনো গেস্ট সংযোগের সমস্যার কথা জানালে এটিই হওয়া উচিত তাদের প্রথম প্রশ্ন। মূল কারণ নম্বর ছয়: MAC অ্যাড্রেস র্যান্ডমাইজেশন সেশনের স্থায়িত্ব নষ্ট করে। আধুনিক iOS এবং Android ডিভাইসগুলি ডিফল্টরূপে একটি গোপনীয়তা বৈশিষ্ট্য হিসাবে র্যান্ডমাইজড MAC অ্যাড্রেস ব্যবহার করে। প্রতিবার যখন একটি ডিভাইস কোনো নেটওয়ার্কে সংযুক্ত হয়, এটি একটি ভিন্ন MAC অ্যাড্রেস প্রদর্শন করতে পারে। যেহেতু Captive Portal সেশনের স্থিতি MAC অ্যাড্রেস দ্বারা ট্র্যাক করা হয়, তাই এক ঘন্টা আগে প্রমাণীকরণ করা একজন গেস্টকে তার ডিভাইসের MAC পরিবর্তিত হওয়ার পরে আবার লগইন পেজটি দেখানো হতে পারে। গেস্ট-মুখী সমাধান হলো নেটওয়ার্ক সেটিংসে আপনার নির্দিষ্ট SSID-এর জন্য Private Address নিষ্ক্রিয় করা। অপারেটর-পার্শ্বের সমাধান হলো প্রোফাইল-ভিত্তিক প্রমাণীকরণ বাস্তবায়ন করা - যেমন Passpoint এবং 802.1X-এর মাধ্যমে OpenRoaming - যা MAC অ্যাড্রেসের পরিবর্তে ক্রেডেন্সিয়াল ব্যবহার করে Layer 2-এ প্রমাণীকরণ করে, যার ফলে র্যান্ডমাইজেশন আর কোনো প্রভাব ফেলে না। এখন বাস্তবায়ন নিয়ে আলোচনা করা যাক। একটি সুconfigured Captive Portal ডিপ্লয়মেন্ট বাস্তবে আসলে কেমন দেখায়? আপনার DHCP আর্কিটেকচার দিয়ে শুরু করুন। ২০০টির বেশি সমবর্তী ডিভাইসের প্রত্যাশা করে এমন যেকোনো ভেন্যুর জন্য, একটি একক স্ল্যাশ-২৪ সাবনেট থেকে সরে আসুন। স্ল্যাশ-২২ বা তার চেয়ে বড় সাবনেট ব্যবহার করুন এবং আপনার ভেন্যুর ড্বেল প্রোফাইলের সাথে মিলিয়ে লিজের সময় সেট করুন। একটি হোটেল লিজের সময় ৮ ঘন্টা সেট করে। একটি স্টেডিয়াম ৩ ঘন্টা সেট করে। একটি শপিং সেন্টার ৯০ মিনিট সেট করে। একটি কনফারেন্স সেন্টার ৩০ মিনিট সেট করে। পরবর্তী পদক্ষেপ, প্রতিবার বড় ইভেন্টের আগে আপনার ওয়াল্ড গার্ডেন যাচাই করুন। সর্বনিম্ন প্রয়োজনীয় এন্ট্রিগুলি হলো: আপনার পোর্টালের ফুলি কোয়ালিফাইড ডোমেন নেম এবং সমস্ত সম্পর্কিত CDN ডোমেন, Apple, Google, Windows এবং Firefox-এর জন্য Captive Portal সনাক্তকরণ URL এবং আপনার সমর্থিত প্রতিটি সোশ্যাল লগইন প্রদানকারীর জন্য OAuth ডোমেন। Purple-এর প্ল্যাটফর্মে, আমরা আমাদের ক্লাউড-ম্যানেজড সার্ভিসের অংশ হিসাবে এই ওয়াল্ড গার্ডেন এন্ট্রিগুলি স্বয়ংক্রিয়ভাবে রক্ষণাবেক্ষণ এবং আপডেট করি, যা আপনার টিমের ম্যানুয়াল রক্ষণাবেক্ষণের বোঝা দূর করে। আপনার পোর্টাল সার্টিফিকেটের জন্য, একটি স্বীকৃত সার্টিফিকেট অথরিটি থেকে সর্বজনীনভাবে বিশ্বস্ত TLS সার্টিফিকেট ব্যবহার করুন। সেলফ-সাইনড সার্টিফিকেটগুলি প্রতিটি ডিভাইসে ব্রাউজার ওয়ার্নিং ট্রিগার করবে। মেয়াদ শেষ হওয়ার আগেই সার্টিফিকেট রিনিউ করুন - একটি মেয়াদোত্তীর্ণ সার্টিফিকেট হলো হঠাৎ, ভেন্যু-ব্যাপী পোর্টাল ব্যর্থতার অন্যতম সাধারণ কারণ। একটি ফাঁদ যা অনেক IT টিমকে বিপদে ফেলে: পূর্বে প্রমাণীকরণ করা একটি ডিভাইস থেকে পোর্টালটি পরীক্ষা করা। আপনার ডিভাইসের সেশনটি এখনও সক্রিয় থাকে, তাই আপনি পোর্টালটিকে সম্পূর্ণরূপে বাইপাস করেন এবং সিদ্ধান্ত নেন যে সবকিছু ঠিকঠাক কাজ করছে। সর্বদা একটি নতুন, অপ্রমাণিত অবস্থায় থাকা ডিভাইস থেকে পরীক্ষা করুন - হয় একটি নতুন ডিভাইস, অথবা এমন একটি ডিভাইস যেখানে আপনি নেটওয়ার্কটি ফরগেট করেছেন এবং WiFi প্রোফাইলটি মুছে ফেলেছেন।আসুন আপনাকে দুটি বাস্তব-জগতের পরিস্থিতি বলি যা এই নীতিগুলির ব্যাখ্যা করে। পরিস্থিতি এক: সেন্ট্রাল লন্ডনের একটি ৩৫০টি রুমের হোটেল। এই প্রপার্টিটি গেস্ট WiFi-এর জন্য একটি একক স্ল্যাশ-২৪ সাবনেট চালাত। একটি বড় কনফারেন্স চলাকালীন, ৪০০ জন প্রতিনিধি একই সাথে উপস্থিত হন। ২০ মিনিটের মধ্যে, DHCP পুল খালি হয়ে যায়। গেস্টরা রিপোর্ট করেন যে তারা কানেক্টেড আছেন কিন্তু Captive Portal বা ইন্টারনেটে পৌঁছাতে পারছেন না। এর তাৎক্ষণিক সমাধান ছিল সাবনেটকে স্ল্যাশ-২২-এ প্রসারিত করা, যার ফলে ১,০২২টি ব্যবহারযোগ্য অ্যাড্রেস পাওয়া যায়, এবং লিজের সময় ২৪ ঘণ্টা থেকে কমিয়ে ৮ ঘণ্টা করা। দীর্ঘমেয়াদী সমাধান ছিল Purple-এর ক্লাউড-ম্যানেজড Captive Portal ইমপ্লিমেন্ট করা, যা রিয়েল-টাইমে DHCP পুলের ব্যবহার পর্যবেক্ষণ করে এবং খালি হওয়ার আগেই নেটওয়ার্ক টিমকে অ্যালার্ট পাঠায়। এই পরিবর্তনের ৪৮ ঘণ্টার মধ্যে পোর্টালের ব্যর্থতার হার প্রায় শূন্যে নেমে আসে। পরিস্থিতি দুই: ২০০টি স্টোর বিশিষ্ট একটি বড় রিটেইল চেইন। চেইনটি তাদের গেস্ট পোর্টালে Google এবং Facebook-এর মাধ্যমে সোশ্যাল লগইন ব্যবহার করত। Google তার OAuth ইনফ্রাস্ট্রাকচার আপডেট করার পর, নতুন অথেন্টিকেশন ডোমেইনগুলি ওয়াল্ড গার্ডেনে (walled garden) ছিল না। গেস্টরা পোর্টাল পেজে পৌঁছাতে পারছিলেন কিন্তু সোশ্যাল লগইন বাটনগুলিতে ক্লিক করলে ব্ল্যাঙ্ক স্ক্রিন দেখাচ্ছিল। চেইনটির IT টিম ওয়াল্ড গার্ডেনের এই ত্রুটি সনাক্ত করার আগে সমস্যাটি নির্ণয় করতে দুই দিন সময় ব্যয় করে। সনাক্ত করার পর সমাধান করতে মাত্র ১০ মিনিট সময় লেগেছিল। শিক্ষা: ক্লাউড-ভিত্তিক OAuth প্রোভাইডারদের জন্য আপনার ওয়াল্ড গার্ডেনে কখনই আইপি অ্যাড্রেস হার্ডকোড করবেন না। ওয়াইল্ডকার্ড ডোমেন এন্ট্রি ব্যবহার করুন এবং প্রতি ত্রৈমাসিকে সেগুলি রিভিউ করুন। এখন ভেন্যু IT টিমের কাছ থেকে নিয়মিত শুনতে পাওয়া কিছু দ্রুত জিজ্ঞাসার উত্তর দেওয়া যাক। পোর্টালটি কেন iPhone-এ কাজ করে কিন্তু Android ডিভাইসে কাজ করে না? Android তার প্রোব URL হিসেবে connectivitycheck.gstatic.com ব্যবহার করে। যদি সেই ডোমেনটি আপনার ফায়ারওয়াল দ্বারা ব্লক করা থাকে বা আপনার ওয়াল্ড গার্ডেনে না থাকে, তবে Android ডিভাইসগুলি কখনই পোর্টালটি ট্রিগার করে না। এটি স্পষ্টভাবে যোগ করুন। একজন গেস্ট বলছেন যে পোর্টালটি লোড হয়েছে কিন্তু লগইন করার পর তারা অনলাইন হতে পারছেন না। এটি প্রায় সবসময়ই একটি RADIUS অথরাইজেশন ব্যর্থতা। আপনার ওয়্যারলেস কন্ট্রোলার থেকে RADIUS সার্ভারটি অ্যাক্সেসযোগ্য কিনা তা পরীক্ষা করুন, শেয়ারড সিক্রেটটি উভয় পাশে মিলছে কিনা তা যাচাই করুন, এবং Access-Reject মেসেজের জন্য RADIUS লগগুলি রিভিউ করুন। কয়েক মিনিট পর পর লগ আউট হয়ে যাওয়া গেস্টদের আমরা কীভাবে হ্যান্ডেল করব? আপনার আইডল টাইমআউট (idle timeout) সেটিং পরীক্ষা করুন। অনেক কন্ট্রোলার ডিফল্টরূপে ৫ মিনিটের আইডল টাইমআউট সেট করে রাখে, যা ইন্টারঅ্যাকশনের মাঝে স্লিপ মোডে চলে যাওয়া মোবাইল ডিভাইসগুলির জন্য অত্যন্ত আগ্রাসী। হসপিটালিটি এবং রিটেইল পরিবেশের জন্য আইডল টাইমআউট কমপক্ষে ৩০ মিনিট সেট করুন। আজকের ব্রিফিংয়ের মূল পয়েন্টগুলি সংক্ষেপে বলতে গেলে: গেস্ট WiFi Captive Portal-এর ব্যর্থতাগুলি ছয়টি ক্যাটাগরির মধ্যে পড়ে: DHCP পুল খালি হওয়া, DNS ইন্টারসেপশন ব্যর্থতা, অসম্পূর্ণ ওয়াল্ড গার্ডেন, HSTS রিডাইরেক্ট ব্লকিং, ক্লায়েন্ট ডিভাইসে সক্রিয় VPN, এবং MAC অ্যাড্রেস র্যান্ডমাইজেশন। প্রতিটিরই একটি নির্দিষ্ট, পরীক্ষাযোগ্য সমাধান রয়েছে। আপনার IT টিমের জন্য তাৎক্ষণিক করণীয় কাজগুলি হলো: আপনার DHCP লিজের সময় এবং সাবনেট সাইজিং অডিট করুন, আপনার সোশ্যাল লগইন প্রোভাইডারদের বর্তমান OAuth ডোমেনের বিপরীতে আপনার ওয়াল্ড গার্ডেন যাচাই করুন, এবং প্রতিটি কনফিগারেশন পরিবর্তনের পর একটি নতুন আন-অথেন্টিকেটেড ডিভাইস থেকে আপনার পোর্টাল পরীক্ষা করুন। আপনার দীর্ঘমেয়াদী রোডম্যাপের জন্য, ফেরত আসা ভিজিটরদের ক্ষেত্রে Captive Portal পুনঃ-অথেন্টিকেশন-এর উত্তরসূরি হিসেবে OpenRoaming-কে মূল্যায়ন করুন। এই প্রযুক্তিটি এখন পরিপক্ক, IEEE 802.1X এবং WPA3-Enterprise-এর অধীনে এর স্ট্যান্ডার্ডগুলো প্রতিষ্ঠিত, এবং Purple এটিকে Connect প্ল্যানের অধীনে কোনো অতিরিক্ত সফটওয়্যার খরচ ছাড়াই সহজলভ্য করেছে। Purple ৮০,০০০-এরও বেশি ভেন্যুতে কাজ করে এবং শুধুমাত্র ২০২৪ সালেই ৪৪০ মিলিয়ন লগইন প্রসেস করেছে। আমরা এই ব্রিফিংয়ে বর্ণিত প্রতিটি ব্যর্থতার ধরণ দেখেছি - এবং সেগুলো প্রতিরোধ করার জন্য টুলিং তৈরি করেছি। আপনার বিদ্যমান Cisco Meraki, HPE Aruba, Ruckus, অথবা Juniper Mist ইনফ্রাস্ট্রাকচারের সাথে Purple-এর ক্লাউড ওভারলে কীভাবে একীভূত হয় তা অন্বেষণ করতে, purple.ai ভিজিট করুন অথবা আপনার অ্যাকাউন্ট ম্যানেজারের সাথে কথা বলুন। শোনার জন্য আপনাকে ধন্যবাদ।

আমাদের মূল সিরিজের অংশ: Captive Portal নির্দেশিকা →

Interactive Network Diagnostic Tool

Public WiFi & Captive Portal Redirection Diagnostic Tool

Diagnose the root cause of splash page redirection failures, probe timeouts, and 'Connected, No Internet' errors across client operating systems and enterprise wireless controllers.

Diagnosis for:Apple iOS (iPhone / iPad)+Cisco Meraki

Root Cause Mechanism

The wireless controller or gateway is failing to intercept cleartext HTTP port 80 requests, or DNS queries for probe domains are being dropped by upstream firewalls before authentication.

Client OS Captive Portal Probe Details
Probe URL:http://captive.apple.com/hotspot-detect.html
Expected Success Status:HTTP 200 with "Success" body string
Detection Daemon:Captive Network Assistant (CNA daemon)
OS behaviour: Fires instantly upon L2 association. If HTTP 302 is received, opens a restricted modal web sheet without full Safari features (e.g. strict cookie storage, no tabs).

Recommended Remediation Actions

  1. Verify that UDP port 53 (DNS) is completely open in pre-authentication firewall policies to allow probe domain resolution.
  2. Ensure the AP or gateway intercepts cleartext HTTP requests (TCP 80) and issues an immediate HTTP 302 Found redirect to the portal URL.
  3. Do not intercept HTTPS port 443 before authentication, as HSTS and TLS SNI mismatches will trigger security warnings.
  4. Instruct users to test manual fallback URLs such as http://neverssl.com or http://captive.apple.com to trigger redirection.
Cisco Meraki Walled Garden & Controller Path:

Configuration Location: Wireless > Configure > Access control > Splash page

# Meraki Dashboard Configuration
1. Set Association Requirements to "Open (no encryption)"
2. Set Splash page to "Sign-on splash page / External captive portal"
3. In "Walled garden", add: *.purple.ai, *.purpleserver.net
4. Enable "RADIUS CoA (RFC 5176)" on port 3799
Pre-auth walled garden FQDNs: *.purple.ai*.purpleserver.net
Do not add the OS probe hosts (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com): if they answer before login, the device decides it is online and never shows the portal.

Eliminate Public WiFi Redirection Failures Across Your Estate

Purple's hardware-agnostic cloud guest WiFi platform eliminates captive portal drops, delivers sub-second splash page loading, and manages pre-auth walled gardens across Cisco Meraki, Aruba, Ruckus, and UniFi.

Useful? Link to this tool

Executive Summary

Public WiFi ট্রাবলশুটিং: 'Connected, No Internet' এবং স্প্ল্যাশ পেজ রিডাইরেকশন ব্যর্থতা সমাধান করা

একজন অতিথি আপনার WiFi নেটওয়ার্কের সাথে যুক্ত হন, কিন্তু লগইন পৃষ্ঠাটি লোড হতে ব্যর্থ হয়। তারা একটি 'সংযুক্ত, ইন্টারনেট নেই' সতর্কতা দেখতে পান এবং চেষ্টা করা ছেড়ে দেন। Venue Operations Directors এবং IT Managers-দের জন্য, এই ব্যর্থতা অতিথিদের অভিজ্ঞতার সরাসরি অবনতি ঘটায়, সাপোর্ট টিকিটের সংখ্যা বৃদ্ধি করে এবং ফার্স্ট-পার্টি ডেটা সংগ্রহ করার একটি বড় সুযোগ নষ্ট করে, যা মূলত ওয়্যারলেস পরিকাঠামোয় বিনিয়োগের যৌক্তিকতাকে প্রমাণ করে।

এই নির্দেশিকাটি অবিকল ব্যাখ্যা করে যে কিভাবে অপারেটিং সিস্টেম স্তরে Captive Portal সনাক্তকরণ কাজ করে এবং বেশিরভাগ সংযোগ ব্যর্থতার জন্য দায়ী ছয়টি মূল কারণ চিহ্নিত করে। এটি DHCP ক্লান্তি, DNS ইন্টারসেপশন ব্যর্থতা, অসম্পূর্ণ walled gardens, অবরুদ্ধ HSTS রিডাইরেক্ট, সক্রিয় VPN দ্বন্দ্ব এবং MAC address randomisation সমস্যা সমাধানের জন্য একটি ব্যবহারিক, ভেন্ডর-নিরপেক্ষ ট্রাবলশুটিং ফ্রেমওয়ার্ক প্রদান করে।

Technical Deep-Dive: How Captive Portal Detection Actually Works

একটি captive portal ট্রাবলশুট করার জন্য, আপনাকে প্রথমে বুঝতে হবে যে নেটওয়ার্ক স্তরে একটি captive portal আসলে কী কাজ করে। এটি কেবল একটি লগইন পৃষ্ঠা নয় - এটি একটি নেটওয়ার্ক স্তরের ট্রাফিকের ইন্টারসেপশন প্রক্রিয়া।

যখন একটি অতিথি ডিভাইস কোনো অতিথি SSID-এ যুক্ত হয়, তখন এটি DHCP-এর মাধ্যমে একটি IP ঠিকানা পায়। অপারেটিং সিস্টেম ব্যবহারকারীর ব্রাউজার খোলার জন্য অপেক্ষা করে না। এর পরিবর্তে, একটি ব্যাকগ্রাউন্ড সিস্টেম সার্ভিস অবিলম্বে একটি ভেন্ডর-নিয়ন্ত্রিত প্রোব URL-এ একটি আনএনক্রিপ্টেড HTTP GET অনুরোধ পাঠায়। Apple ডিভাইসগুলি captive.apple.com কোয়েরি করে। Android ডিভাইসগুলি connectivitycheck.gstatic.com কোয়েরি করে। Windows ডিভাইসগুলি msftconnecttest.com কোয়েরি করে। Firefox ডিভাইসগুলি detectportal.firefox.com কোয়েরি করে।

নেটওয়ার্কে যদি উন্মুক্ত ইন্টারনেট অ্যাক্সেস থাকে, তবে এই প্রোবগুলি তাদের প্রত্যাশিত HTTP 200 OK রেসপন্স ফেরত দেয় এবং অপারেটিং সিস্টেম সিদ্ধান্ত নেয় যে সংযোগটি সক্রিয় আছে। তবে, কোনো অতিথি নেটওয়ার্কে, ওয়্যারলেস গেটওয়ে বা কন্ট্রোলার এই HTTP প্রোবটি ইন্টারনেটে পৌঁছানোর আগেই ইন্টারসেপ্ট বা বাধা দেয়। প্রত্যাশিত রেসপন্সের পরিবর্তে, গেটওয়েটি একটি HTTP 307 Temporary Redirect ফেরত পাঠায় যা captive portal-এর স্প্ল্যাশ পৃষ্ঠাটিকে নির্দেশ করে। অপারেটিং সিস্টেম এই অপ্রত্যাশিত রিডাইরেক্ট সনাক্ত করে, বুঝতে পারে যে এটি একটি captive portal-এর পিছনে রয়েছে এবং লগইন পৃষ্ঠাটি প্রদর্শনের জন্য একটি স্যান্ডবক্সড ব্রাউজার উইন্ডো (Captive Network Assistant) খোলে।

Public WiFi ট্রাবলশুটিং: 'Connected, No Internet' এবং স্প্ল্যাশ পেজ রিডাইরেকশন ব্যর্থতা সমাধান করা - portal architecture dia…

আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?

আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।

Troubleshooting & Risk Mitigation: The 6 Root Causes of Failure

যখন একটি captive portal লোড হতে ব্যর্থ হয়, তখন সেই সমস্যাটি প্রায় সবসময়ই ছয়টি নির্দিষ্ট ব্যর্থতার মোডের কোনো একটির কারণে ঘটে থাকে।

Public WiFi ট্রাবলশুটিং: 'Connected, No Internet' এবং স্প্ল্যাশ পেজ রিডাইরেকশন ব্যর্থতা সমাধান করা - root causes infographic

১. DHCP পুল ফুরিয়ে যাওয়া

উচ্চ ঘনত্বের ইভেন্টগুলিতে এটি একটি নীরব ঘাতক। আপনি যদি ২,০০০ জন অংশগ্রহণকারী নিয়ে একটি কনফারেন্স পরিচালনা করেন এবং একটি স্ট্যান্ডার্ড /২৪ সাবনেট ব্যবহার করেন, তাহলে আপনার কাছে মাত্র ২৫৪টি ব্যবহারযোগ্য IP অ্যাড্রেস থাকবে। আপনার DHCP লিজের সময় যদি ডিফল্ট ২৪ ঘণ্টা সেট করা থাকে, তবে দরজা খোলার কয়েক মিনিটের মধ্যেই আপনার পুলটি ফুরিয়ে যাবে। এর পরে প্রতিটি সংযোগের চেষ্টা Captive Portal সিকোয়েন্স শুরু হওয়ার আগেই ব্যর্থ হবে।

সমাধান: উচ্চ-টার্নওভার পরিবেশের জন্য গেস্ট DHCP লিজের সময় ১৫ থেকে ৩০ মিনিটের মধ্যে সেট করুন। শুধুমাত্র গড় উপস্থিতির ওপর ভিত্তি করে নয়, পিক কনকারেন্ট ইউজারদের সংখ্যা অনুযায়ী আপনার সাবনেটের আকার নির্ধারণ করুন। একটি /২২ সাবনেট ১,০২২টি ব্যবহারযোগ্য অ্যাড্রেস প্রদান করে, যা এন্টারপ্রাইজ ভেন্যুগুলির জন্য প্রস্তাবিত সর্বনিম্ন সাইজ।

২. DNS ইন্টারসেপশন ব্যর্থতা

Captive Portal রিডাইরেকশন গেটওয়ে দ্বারা একটি HTTP প্রোব ইন্টারসেপ্ট করার ওপর নির্ভর করে। তবে, সেই প্রোবের জন্য প্রথমে একটি DNS লুকআপের প্রয়োজন হয়। আপনার DNS কনফিগারেশন যদি প্রি-অথেন্টিকেটেড ক্লায়েন্টদের এক্সটার্নাল ডোমেইন নেম রিসলভ করার অনুমতি না দেয়, তবে প্রোবটি কখনোই ফায়ার হবে না।

সমাধান: আপনার ফায়ারওয়াল পলিসিগুলি যাতে স্পষ্টভাবে অনঅথেন্টিকেটেড ক্লায়েন্টদের থেকে DNS কোয়েরি (পোর্ট ৫৩) অনুমোদন করে তা নিশ্চিত করুন। আপনার DNS ইন্টারসেপশন কাজ করছে কিনা তা যাচাই করতে একটি টেস্ট ডিভাইসে প্যাকেট ক্যাপচার রান করুন।

৩. অসম্পূর্ণ অল্ড গার্ডেন

অল্ড গার্ডেন (প্রি-অথেনটিকেশন অ্যাক্সেস কন্ট্রোল লিস্ট) নির্ধারণ করে যে অনঅথেন্টিকেটেড গেস্টরা কোন কোন এক্সটার্নাল ডোমেইনে পৌঁছাতে পারবে। আপনার পোর্টাল স্প্ল্যাশ পেজটি যদি এমন কোনো CDN থেকে অ্যাসেট লোড করে যা অল্ড গার্ডেনের অন্তর্ভুক্ত নয়, তবে পেজটি একটি ফাঁকা স্ক্রিন হিসেবে রেন্ডার হবে। আপনি যদি Google, Apple, বা Microsoft Entra ID এর মাধ্যমে সোশ্যাল লগইন অফার করেন, তবে সেইসব প্রোভাইডারদের দ্বারা ব্যবহৃত প্রতিটি ওঅথ ডোমেইন অবশ্যই হোয়াইটলিস্টেড হতে হবে। সোশ্যাল আইডেন্টিটি প্রোভাইডাররা নিয়মিত তাদের CDN IP রেঞ্জ এবং অথেনটিকেশন ডোমেইন আপডেট করে; তাই ছয় মাস আগে নিখুঁতভাবে কাজ করা একটি অল্ড গার্ডেন রাতারাতি ভেঙে যেতে পারে।

সমাধান: ত্রৈমাসিক অল্ড গার্ডেন অডিট শিডিউল করুন। যেখানে আপনার হার্ডওয়্যার এটি সাপোর্ট করে, সেখানে ওয়াইল্ডকার্ড ডোমেইন স্নুপিং ব্যবহার করুন, যা Cisco Meraki, HPE Aruba, Ruckus, এবং Juniper Mist-এ নেটিভলি উপলব্ধ। Purple আমাদের ক্লাউড-ম্যানেজড সার্ভিসের অংশ হিসেবে এই অল্ড গার্ডেন এন্ট্রিগুলি অটোমেটিকালি রক্ষণাবেক্ষণ ও আপডেট করে।

৪. HSTS রিডাইরেক্ট ব্লকিং

HTTP Strict Transport Security (HSTS) হলো একটি ব্রাউজার সিকিউরিটি পলিসি যা শুধুমাত্র HTTPS-এর মাধ্যমে নির্দিষ্ট ডোমেইনে সংযোগ করতে বাধ্য করে। কোনো গেস্ট ডিভাইস যদি একটি HSTS-প্রিলোডেড ডোমেইনের সাথে যোগাযোগ করার চেষ্টা করে, এবং আপনার গেটওয়ে পোর্টালে রিডাইরেক্ট করার জন্য সেই HTTPS রিকোয়েস্টটি ইন্টারসেপ্ট করার চেষ্টা করে, তবে ব্রাউজার একটি সার্টিফিকেট মিসম্যাচ শনাক্ত করে। এটি একটি এড়ানো অসম্ভব সিকিউরিটি ওয়ার্নিং প্রদর্শন করে এবং রিডাইরেক্ট সম্পূর্ণরূপে ব্লক করে দেয়। সমাধান: প্রাথমিক রিডাইরেক্টের জন্য কখনই HTTPS ইন্টারসেপশন করার চেষ্টা করবেন না। আপনার গেটওয়ে যাতে শুধুমাত্র আনএনক্রিপ্টেড HTTP কেয়ারী প্রোব রিডাইরেক্ট করে তা নিশ্চিত করুন। দীর্ঘমেয়াদী মানক-ভিত্তিক সমাধান হল RFC 8910, যা DHCP Option 114 সংজ্ঞায়িত করে। এই অপশনটি আপনার DHCP সার্ভারকে সরাসরি ক্লায়েন্ট ডিভাইসে Captive Portal URL-টি বিজ্ঞাপন করার অনুমতি দেয়, যা HTTP রিডাইরেকশনের প্রয়োজনীয়তাকে সম্পূর্ণরূপে এড়িয়ে যায়। iOS 14 এবং Android 11 এবং তার পরবর্তী সংস্করণগুলি এটিকে নেটিভভাবে সমর্থন করে।

5. ক্লায়েন্ট ডিভাইসে সক্রিয় VPN

একটি VPN ডিভাইস থেকে আসা সমস্ত ট্রাফিককে এনক্রিপ্ট করে এবং আপনার গেটওয়েতে পৌঁছানোর আগে এটিকে একটি বাহ্যিক টানেলের মাধ্যমে রুট করে। আপনার গেটওয়ে কখনই HTTP প্রোব দেখতে পায় না, তাই Captive Portal সনাক্তকরণ সিকোয়েন্স কখনই ট্রিগার হয় না। অতিথিরা লগইন পৃষ্ঠা বা ইন্টারনেট কোনোটাই দেখতে পান না।

সমাধান: অতিথিকে অবশ্যই VPN নিষ্ক্রিয় করতে হবে, পোর্টালে সংযুক্ত হতে হবে এবং তারপরে পুনরায় VPN সক্রিয় করতে হবে। ফ্রন্ট-অফ-হাউস কর্মীদের জন্য, অতিথি VPN ব্যবহার করছেন কিনা তা জিজ্ঞাসা করা প্রথম সমস্যা সমাধানের ধাপ হওয়া উচিত।

6. MAC Address Randomisation-এর কারণে সেশন পারসিস্টেন্স ব্যাহত হওয়া

আধুনিক iOS এবং Android ডিভাইসগুলি গোপনীয়তার বৈশিষ্ট্য হিসেবে ডিফল্টরূপে র্যান্ডমাইজড MAC অ্যাড্রেস ব্যবহার করে। প্রতিবার কোনো ডিভাইস একটি নেটওয়ার্কে সংযুক্ত হওয়ার সময়, এটি একটি ভিন্ন MAC অ্যাড্রেস উপস্থাপন করতে পারে। যেহেতু Captive Portal সেশনের স্থিতি MAC অ্যাড্রেস দ্বারা ট্র্যাক করা হয়, তাই এক ঘন্টা আগে প্রমাণীকৃত একজন অতিথিকে তার ডিভাইসের MAC পরিবর্তিত হওয়ার পরে আবার লগইন পৃষ্ঠাটি দেখানো হতে পারে।

সমাধান: অতিথিদের জন্য সমাধান হল তাদের নেটওয়ার্ক সেটিংসে আপনার নির্দিষ্ট SSID-এর জন্য Private Address নিষ্ক্রিয় করা। অপারেটর-সাইড সমাধান হল প্রোফাইল-ভিত্তিক প্রমাণীকরণ প্রয়োগ করা, যেমন 802.1X-এর মাধ্যমে Passpoint এবং OpenRoaming, যা MAC অ্যাড্রেসের পরিবর্তে ক্রেডেন্সিয়াল ব্যবহার করে লেয়ার ২-এ প্রমাণীকরণ করে, যার ফলে র্যান্ডমাইজেশন অপ্রাসঙ্গিক হয়ে পড়ে।

বাস্তবায়ন নির্দেশিকা: একটি স্থিতিস্থাপক আর্কিটেকচার তৈরি করা

একটি সুসংconfigured Captive Portal স্থাপন করার জন্য সক্রিয় আর্কিটেকচারাল সিদ্ধান্তের প্রয়োজন হয়।

১. প্রতিটি বড় ইভেন্টের আগে আপনার ওয়াল্ড গার্ডেন যাচাই করুন। ন্যূনতম প্রয়োজনীয় এন্ট্রিগুলি হল: আপনার পোর্টালের FQDN এবং সমস্ত সম্পর্কিত CDN ডোমেন, Apple, Google, Windows, এবং Firefox-এর জন্য Captive Portal সনাক্তকরণ URL-গুলি, এবং আপনার সমর্থিত প্রতিটি সোশ্যাল লগইন প্রদানকারীর জন্য OAuth ডোমেনগুলি। ২. একটি সর্বজনীনভাবে বিশ্বস্ত TLS সার্টিফিকেট ব্যবহার করুন। স্ব-স্বাক্ষরিত সার্টিফিকেট প্রতিটি ডিভাইসে ব্রাউজার সতর্কতা ট্রিগার করবে। সার্টিফিকেটগুলির মেয়াদ শেষ হওয়ার আগেই সেগুলি পুনর্নবীকরণ করুন; মেয়াদোত্তীর্ণ সার্টিফিকেট হল হঠাৎ, ভেন্যু-ব্যাপী পোর্টাল ব্যর্থতার অন্যতম সাধারণ কারণ। ৩. একটি নতুন, অপ্রমাণীকৃত অবস্থা থেকে পরীক্ষা করুন। পূর্বে প্রমাণীকৃত ডিভাইস থেকে পোর্টাল পরীক্ষা করলে পোর্টালটি সম্পূর্ণরূপে এড়িয়ে যাবে কারণ সেশনটি এখনও সক্রিয় রয়েছে। সর্বদা একটি নতুন ডিভাইস থেকে পরীক্ষা করুন, অথবা এমন একটি ডিভাইস থেকে যেখানে আপনি নেটওয়ার্কটি ফরগেট করেছেন এবং WiFi প্রোফাইলটি মুছে ফেলেছেন। ৪. আইডল টাইমআউট সামঞ্জস্য করুন। অনেক কন্ট্রোলার ডিফল্টরূপে ৫ মিনিটের আইডল টাইমআউট ব্যবহার করে, যা ইন্টারঅ্যাকশনের মধ্যে স্লিপ মোডে চলে যাওয়া মোবাইল ডিভাইসগুলির জন্য অত্যন্ত আক্রমণাত্মক। হসপিটালিটি এবং রিটেল পরিবেশের জন্য আইডল টাইমআউট কমপক্ষে ৩০ মিনিটে সেট করুন।

ROI এবং ব্যবসায়িক প্রভাব

Captive Portal একটি পরিপক্ক প্রযুক্তি, তবে এর কিছু সহজাত জটিলতা রয়েছে। আমাদের কৌশলগত লক্ষ্য হলো নিরবচ্ছিন্ন এবং নিরাপদ অথেনটিকেশনের দিকে এগিয়ে যাওয়া।

Passpoint এবং 802.1X এর ওপর ভিত্তি করে তৈরি OpenRoaming, কোনো লগইন পৃষ্ঠা না দেখিয়েই ফিরে আসা অতিথিদের স্বয়ংক্রিয়ভাবে এবং নিরাপদে সংযুক্ত হতে সাহায্য করে। আমাদের Connect প্ল্যানের অধীনে, Purple, OpenRoaming-এর জন্য একটি বিনামূল্যের আইডেন্টিটি প্রোভাইডার হিসেবে কাজ করে। Premier Inn এবং Manchester Airports Group-এর মতো ভেন্যুগুলো পুনরাবৃত্ত দর্শনার্থীদের জন্য পুনরায় অথেনটিকেশনের ঝামেলা দূর করতে ইতিমধ্যেই এটি ব্যবহার করছে, এবং একই সাথে সম্পূর্ণ GDPR সম্মতি ও ফার্স্ট-পার্টি ডেটা সংগ্রহ বজায় রাখছে। সংযোগের ব্যর্থতা হ্রাস করে, আপনি সরাসরি সংগৃহীত ফার্স্ট-পার্টি ডেটার পরিমাণ বাড়াতে পারেন, যা গ্রাহকের আনুগত্য এবং ব্যক্তিগতকৃত সম্পৃক্ততা বৃদ্ধি করে।

টেকনিক্যাল ব্রিফিং পডকাস্ট

আমাদের ১০ মিনিটের টেকনিক্যাল ব্রিফিং-এ আমাদের সিনিয়র সলিউশন আর্কিটেক্টের কাছ থেকে এই ট্রাবলশুটিং পদক্ষেপগুলোর একটি বিস্তারিত বিশ্লেষণ শুনুন।

মূল সংজ্ঞাসমূহ

Captive Portal

একটি নেটওয়ার্ক-স্তরের ট্রাফিক ইন্টারসেপশন মেকানিজম যা কোনো ব্যবহারকারী একটি প্রয়োজনীয় পদক্ষেপ সম্পূর্ণ না করা পর্যন্ত, যেমন একটি স্প্ল্যাশ পেজে শর্তাবলী স্বীকার করা বা ক্রেডেনশিয়াল প্রদান করা, ইন্টারনেট অ্যাক্সেস সীমাবদ্ধ করে।

এন্টারপ্রাইজ ভেন্যুগুলির জন্য গেস্ট অ্যাক্সেস সুরক্ষিত করার এবং ফার্স্ট-পার্টি ডেটা সংগ্রহ করার প্রাথমিক পদ্ধতি।

Walled Garden

একটি প্রি-অথেন্টিকেশন অ্যাক্সেস কন্ট্রোল লিস্ট যা নির্ধারণ করে কোনো অথেন্টিকেটেড না হওয়া গেস্ট ডিভাইস কোন কোন বাহ্যিক IP ঠিকানা বা ডোমেনে পৌঁছানোর অনুমতি পাবে।

ব্যবহারকারী সম্পূর্ণ অথেন্টিকেটেড হওয়ার আগে পোর্টাল রিসোর্স, CDN এবং OAuth আইডেন্টিটি প্রদানকারী অ্যাক্সেস করার অনুমতি দেওয়ার জন্য অত্যন্ত গুরুত্বপূর্ণ।

Captive Network Assistant (CNA)

একটি স্যান্ডবক্সযুক্ত, সীমিত কার্যকারিতার ব্রাউজার উইন্ডো যা কোনো captive portal রিডাইরেক্ট সনাক্ত করার সময় অপারেটিং সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে ওপেন হয়।

এটি এমন ইন্টারফেস যেখানে গেস্ট আসলে আপনার লগইন পৃষ্ঠাটি দেখতে পায় এবং সেটির সাথে ইন্টারঅ্যাক্ট করে।

HSTS (HTTP Strict Transport Security)

একটি ওয়েব সিকিউরিটি পলিসি মেকানিজম যা ব্রাউজারগুলিকে কেবলমাত্র নিরাপদ HTTPS সংযোগের মাধ্যমে ইন্টারঅ্যাক্ট করতে বাধ্য করে ম্যান-ইন-দ্য-মিডল আক্রমণ থেকে ওয়েবসাইটগুলিকে রক্ষা করতে সহায়তা করে।

HSTS গেটওয়েগুলিকে ব্যবহারকারীদের একটি captive portal-এ রিডাইরেক্ট করতে HTTPS ইন্টারসেপশন ব্যবহার করা থেকে বিরত রাখে, যা ভুলভাবে কনফিগার করা হলে সংযোগ ব্যর্থতার কারণ হয়।

DHCP Pool Exhaustion

এমন একটি অবস্থা যেখানে একটি DHCP সার্ভার তার কনফিগার করা সাবনেটের সমস্ত উপলব্ধ IP ঠিকানা বরাদ্দ করে ফেলেছে, যা নতুন ডিভাইসগুলিকে নেটওয়ার্কে যুক্ত হতে বাধা দেয়।

স্টেডিয়াম বা কনফারেন্সের মতো উচ্চ-ঘনত্বের পরিবেশে 'Connected, No Internet' ত্রুটির একটি সাধারণ কারণ।

MAC Address Randomisation

আধুনিক মোবাইল অপারেটিং সিস্টেমের একটি প্রাইভেসি বৈশিষ্ট্য যা প্রতিটি WiFi নেটওয়ার্কের জন্য একটি র্যান্ডম MAC address তৈরি করে, বিভিন্ন স্থানে ট্র্যাকিং প্রতিরোধ করে।

এই বৈশিষ্ট্যটি captive portal-এ সেশন পারসিস্টেন্স নষ্ট করে, যার ফলে গেস্টদের MAC address পরিবর্তিত হলে তাদের আবার অথেন্টিকেট করতে বাধ্য করা হয়।

OpenRoaming

WiFi নেটওয়ার্কের একটি ফেডারেশন যা ব্যবহারকারীদের কোনো ক্রেডেনশিয়াল প্রবেশ করানো বা captive portal-এর সাথে ইন্টারঅ্যাক্ট করা ছাড়াই স্বয়ংক্রিয়ভাবে এবং নিরাপদে অংশগ্রহণকারী নেটওয়ার্কগুলোতে সংযুক্ত হতে দেয়।

পুনরাগত ভিজিটরদের জন্য captive portals-এর কৌশলগত উত্তরসূরি, যা Purple দ্বারা একটি বিনামূল্যের পরিচয় প্রদানকারী হিসেবে সমর্থিত।

RFC 8910 (DHCP Option 114)

একটি স্ট্যান্ডার্ড যা IP অ্যাড্রেস অ্যাসাইনমেন্টের সময় DHCP সার্ভারকে সরাসরি ক্লায়েন্ট ডিভাইসে captive portal-এর URL প্রদান করতে দেয়।

এটি HTTP রিডিরেকশনের প্রয়োজনীয়তাকে সম্পূর্ণরূপে এড়িয়ে যায়, যার ফলে HSTS-এর কারণে সৃষ্ট সমস্যার সমাধান হয় এবং পোর্টাল সনাক্তকরণের গতি উন্নত হয়।

সমাধানকৃত উদাহরণসমূহ

মধ্য লন্ডনের একটি ৩৫০-রুমের হোটেল গেস্ট WiFi-এর জন্য একটি একক /24 সাবনেট পরিচালনা করে। একটি বড় কনফারেন্স চলাকালীন, ৪০০ জন প্রতিনিধি একই সাথে আসেন। ২০ মিনিটের মধ্যে, গেস্টরা সংযুক্ত থাকার কথা রিপোর্ট করলেও পোর্টাল বা ইন্টারনেটে পৌঁছাতে পারছিলেন না।

তাত্ক্ষণিক সমাধান হলো সাবনেটটিকে /22-এ প্রসারিত করা, যা ১,০২২টি ব্যবহারযোগ্য ঠিকানা প্রদান করে এবং DHCP লিজের সময় ২৪ ঘণ্টা থেকে কমিয়ে ৮ ঘণ্টা করা। দীর্ঘমেয়াদী সমাধান হলো Purple-এর ক্লাউড-ম্যানেজড captive portal প্রয়োগ করা, যা রিয়েল টাইমে DHCP পুলের ব্যবহার পর্যবেক্ষণ করে এবং সম্পূর্ণ শেষ হওয়ার আগেই নেটওয়ার্ক টিমকে সতর্ক করে দেয়।

পরীক্ষকের মন্তব্য: এই পরিস্থিতিটি ক্লাসিক DHCP পুলের ঘাটতি প্রদর্শন করে। একটি /24 সাবনেট কেবল ২৫৪টি ব্যবহারযোগ্য IP ঠিকানা প্রদান করে। সাবনেটের আকার বাড়িয়ে এবং লিজের সময় কমিয়ে, নেটওয়ার্কটি কনফারেন্সের মতো পরিস্থিতিতে সাধারণ ডিভাইসগুলির উচ্চ আনাগোনার সাথে খাপ খাইয়ে নিতে পারে।

২০০টি স্টোর সহ একটি বড় রিটেল চেইন তাদের গেস্ট পোর্টালে Google এবং Facebook-এর মাধ্যমে সোশ্যাল লগইন ব্যবহার করে। Google তার OAuth পরিকাঠামো আপডেট করার পর, গেস্টরা পোর্টাল পেজে পৌঁছাতে পারলেও সোশ্যাল লগইন বোতামগুলোতে ফাঁকা স্ক্রিন দেখায়।

IT টিমকে অবশ্যই Google-এর ব্যবহৃত নতুন অথেন্টিকেশন ডোমেনগুলি সনাক্ত করতে হবে এবং সেগুলিকে walled garden (প্রি-অথেন্টিকেশন অ্যাক্সেস কন্ট্রোল লিস্ট)-এ যুক্ত করতে হবে। ভবিষ্যতে এটি প্রতিরোধ করতে, নির্দিষ্ট IP ঠিকানা হার্ডকোড করার পরিবর্তে তাদের ওয়াইল্ডকার্ড ডোমেন এন্ট্রি (যেমন, *.google.com) ব্যবহার করা উচিত এবং ত্রৈমাসিক ভিত্তিতে walled garden পর্যালোচনা করা উচিত।

পরীক্ষকের মন্তব্য: এটি থার্ড-পার্টি OAuth প্রদানকারীদের ওপর নির্ভর করার সময় স্ট্যাটিক walled garden-এর দুর্বলতাকে তুলে ধরে। ক্লাউড-ভিত্তিক আইডেন্টিটি প্রদানকারীরা ঘন ঘন তাদের IP রেঞ্জ এবং CDN ডোমেন পরিবর্তন করে। Cisco Meraki এবং HPE Aruba-র মতো এন্টারপ্রাইজ হার্ডওয়্যার দ্বারা নেটিভভাবে সমর্থিত ওয়াইল্ডকার্ড স্নুপিং হলো সঠিক আর্কিটেকচারাল পদ্ধতি।

অনুশীলনী প্রশ্নসমূহ

Q1. একটি স্টেডিয়ামের IT ডিরেক্টর জানিয়েছেন যে হাফটাইমের সময় হাজার হাজার দর্শক গেস্ট WiFi-এ সংযোগ করার চেষ্টা করেন। কিছু মানুষের জন্য পোর্টাল লোড হয়, কিন্তু অনেকেই রিপোর্ট করেন যে পোর্টালটি প্রদর্শিত হওয়ার আগেই তাদের ডিভাইসগুলো 'Obtaining IP address' এ আটকে গেছে অথবা 'Connected, No Internet' দেখাচ্ছে। সবচেয়ে সম্ভাব্য আর্কিটেকচারাল ত্রুটি কোনটি?

ইঙ্গিত: নেটওয়ার্ক সেগমেন্টে উপলব্ধ রিসোর্সের তুলনায় একযোগে সক্রিয় কানেকশনের ভলিউম বিবেচনা করুন।

মডেল উত্তর দেখুন

নেটওয়ার্কটি DHCP পুলের ঘাটতি (exhaustion) অনুভব করছে। সাবনেটটি সম্ভবত পিক কনকারেন্ট ইউজার লোডের জন্য খুব ছোট আকারের (যেমন, একটি /24) এবং DHCP লিজ টাইম সম্ভবত খুব বেশি সেট করা হয়েছে। প্রস্তাবিত সমাধান হলো সাবনেটের আকার বাড়ানো (যেমন, /22 বা /21 এ) এবং প্রত্যাশিত অবস্থানের সময়কালের সাথে সামঞ্জস্য রেখে DHCP লিজ টাইম হ্রাস করা (যেমন, স্টেডিয়ামের জন্য 3 ঘণ্টা)।

Q2. একজন গেস্ট আপনার রিটেল WiFi নেটওয়ার্কে সংযুক্ত হয়েছেন। একটি জনপ্রিয় ওয়েবসাইট লোড করার চেষ্টা করার সময় তার ডিভাইসে 'Your connection is not private' লেখা একটি সিকিউরিটি ওয়ার্নিং দেখায় এবং captive portal-টি কখনোই লোড হয় না। কোন মেকানিজম এই ব্লকের সৃষ্টি করছে?

ইঙ্গিত: আধুনিক ব্রাউজারগুলো কীভাবে সুরক্ষিত কানেকশনে জোরপূর্বক রিডিরেকশন পরিচালনা করে তা নিয়ে ভাবুন।

মডেল উত্তর দেখুন

HSTS (HTTP Strict Transport Security) এই রিডিরেকশনটি ব্লক করছে। গেস্ট একটি HSTS-প্রিloaded ডোমেনে (HTTPS-এর মাধ্যমে) নেভিগেট করার চেষ্টা করেছিলেন, এবং ওয়্যারলেস গেটওয়ে পোর্টালের দিকে রিডিরেক্ট করার জন্য সেই সুরক্ষিত কানেকশনটিকে ইন্টারসেপ্ট করার চেষ্টা করেছিল। ব্রাউজার সার্টিফিকেট অমিল সনাক্ত করেছে এবং কানেকশনটি ব্লক করেছে। গেটওয়েটিকে শুধুমাত্র আনএনক্রিপ্টেড HTTP প্রোব ইন্টারসেপ্ট করার জন্য কনফিগার করতে হবে।

Q3. আপনি সম্প্রতি আপনার captive portal-এ Google এবং Microsoft Entra ID সোশ্যাল লগইন অপশনগুলো সক্রিয় করেছেন। গেস্টরা রিপোর্ট করছেন যে পোর্টাল পেজটি লোড হচ্ছে, কিন্তু লগইন বাটনে ক্লিক করলে টাইমআউট হয়ে যাচ্ছে। IT ডিপার্টমেন্টের অবাধ স্টাফ নেটওয়ার্কে টেস্ট করার সময় পোর্টালটি চমৎকারভাবে কাজ করে। কোন কনফিগারেশনটি বাদ পড়েছে?

ইঙ্গিত: অথেন্টিকেশন সম্পন্ন হওয়ার আগে গেস্ট ডিভাইসের নেটওয়ার্ক স্টেট বিবেচনা করুন।

মডেল উত্তর দেখুন

walled garden (প্রি-অথেন্টিকেশন অ্যাক্সেস কন্ট্রোল লিস্ট) অসম্পূর্ণ রয়েছে। Google এবং Microsoft Entra ID দ্বারা ব্যবহৃত OAuth অথেন্টিকেশন ডোমেন এবং CDN-গুলোকে হোয়াইটলিস্ট করা হয়নি। যেহেতু গেস্ট আনঅথেন্টিকেটেড, তাই গেটওয়ে এই এক্সটার্নাল ডোমেনগুলোর অ্যাক্সেস ব্লক করছে, যার ফলে সোশ্যাল লগইন প্রক্রিয়াটি টাইমআউট হয়ে যাচ্ছে। IT টিমকে অবশ্যই walled garden-এ এই আইডেন্টিটি প্রোভাইডারদের জন্য ওয়াইল্ডকার্ড এন্ট্রি যোগ করতে হবে।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

Why does public WiFi fail to redirect to the splash login page?

Public WiFi fails to redirect when the wireless controller or gateway cannot intercept cleartext HTTP requests (TCP port 80), when upstream firewalls drop DNS queries for captive portal probe URLs (such as captive.apple.com or connectivitycheck.gstatic.com), or when modern client browsers enforce HSTS on HTTPS requests before authentication. Allowing pre-authentication DNS and redirecting HTTP traffic resolves the issue.

How do client operating systems detect public WiFi captive portals?

Upon connecting to an open or public WiFi network, iOS fires HTTP requests via Captive Network Assistant (CNA) to captive.apple.com/hotspot-detect.html, Android queries connectivitycheck.gstatic.com/generate_204 via CaptivePortalLogin, and Windows probes msftconnecttest.com/connecttest.txt via NCSI. If the network returns an HTTP 302 redirect, the operating system launches the captive portal webview. If the probe domain fails to resolve or times out, the device marks the connection as having no internet.

Why do users see SSL certificate or HSTS warnings on public WiFi?

When an access point or gateway intercepts encrypted HTTPS requests (port 443) and presents its own self-signed or vendor certificate to force a splash page on public WiFi, modern web browsers detect a domain mismatch and block the connection with an HSTS or untrusted certificate error. Public WiFi networks should only intercept cleartext HTTP port 80 requests or implement RFC 8910 DHCP Option 114 to cleanly announce the portal URL.

What causes public WiFi captive portals to loop back to the login page?

Infinite login loops occur when the wireless access point or controller fails to receive or process the RADIUS Access-Accept packet or RFC 5176 Change of Authorization (CoA) disconnect/re-authenticate message on UDP port 3799. As a result, the controller maintains the client device in the pre-authentication walled garden role despite successful submission of guest credentials on the public WiFi network.

How does Purple eliminate public WiFi splash page redirection failures?

Purple operates as a cloud-delivered, hardware-agnostic guest WiFi management platform across Cisco Meraki, HPE Aruba, Ruckus, Ubiquiti UniFi, and Fortinet architectures. By optimizing captive portal redirection flows, automating walled garden rules, and integrating with high-speed Anycast DNS, Purple ensures detection probes succeed instantly, onboarding visitors in under 3 seconds without connection drops.

এই সিরিজে পড়া চালিয়ে যান

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 ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।