निवासी इमारतींमध्ये हॉटेल-स्टाईल अतिथी WiFi का अयशस्वी ठरते
तुम्ही निदान करू शकाल की BTR ब्लॉक्स, विद्यार्थी वसतिगृहे आणि MDUs मधील रहिवासी वारंवार WiFi दोषांची तक्रार का करत आहेत आणि ते दुरुस्त करणारे ऑथेंटिकेशन मॉडेल निवडू शकाल. याचे उत्तर म्हणजे तुमच्या विद्यमान ऍक्सेस पॉइंट्सवर प्रति-घरगुती iPSK की देणे आणि अभ्यागतांसाठी स्वतंत्र captive portal नेटवर्क ठेवणे.
आमच्या मुख्य मालिकेचा भाग: मल्टी-टेनंट WiFi: संपूर्ण मार्गदर्शक →
रहिवासी इमारतींमध्ये हॉटेल-शैलीतील अतिथी WiFi अपयशी ठरते कारण ते गृहीत धरते की मुक्काम लहान आहे, आणि वापरकर्त्याकडे फोन आणि ब्राउझर आहे. सुसज्ज अपार्टमेंटमध्ये १० किंवा अधिक कनेक्ट केलेली उपकरणे असू शकतात, ज्यापैकी बऱ्याच उपकरणांमध्ये captive portal पूर्ण करण्यासाठी ब्राउझर नसतो, आणि रहिवासी कास्टिंग आणि स्मार्ट-होम किट कार्य करण्याची अपेक्षा करतात. त्याऐवजी प्रत्येक घराला स्वतःची iPSK की आणि खाजगी नेटवर्क सेगमेंट द्या.
रहिवासी इमारतीत अतिथी WiFi चे अपयश नेमके कसे दिसते?
हा दोष क्वचितच नेटवर्क बंद पडण्याच्या स्वरूपात समोर येतो. तो भाडे देणाऱ्या रहिवाशांकडून येणाऱ्या छोट्या तक्रारींच्या प्रवाहाच्या स्वरूपात समोर येतो, जे केवळ तिथून तात्पुरते प्रवास करत नसतात.
बिल्ड-टू-रेंट (BTR) ब्लॉक, स्टुडंट हॉल किंवा मल्टि-ड्वेलिंग युनिट (MDU) मधील ठराविक लक्षणे:
- स्मार्ट TV, स्पीकर किंवा थर्मोस्टॅट कनेक्ट होणार नाही. या उपकरणांमध्ये ब्राउझर नसतो, त्यामुळे ते captive portal पूर्ण करू शकत नाहीत - म्हणजेच प्रवेश देण्यापूर्वी अतिथी नेटवर्क दाखवत असलेले वेब लॉगइन पृष्ठ.
- कास्टिंग अपयशी ठरते. रहिवाशाचा फोन त्यांचे स्वतःचे Chromecast किंवा AirPlay रिसिव्हर शोधू शकत नाही किंवा तो शेजाऱ्याचे रिसिव्हर शोधतो.
- प्रत्येकजण दररोज पुन्हा लॉगइन करतो. पोर्टल सेशन २४ तासांच्या टाइमरवर संपते, जे हॉटेलच्या पाहुण्यांसाठी योग्य आहे परंतु तिथे राहणाऱ्या व्यक्तीला त्रासदायक ठरते.
- सॉफ्टवेअर अपडेटनंतर उपकरणे डिस्कनेक्ट होतात. जे फोन त्यांचे हार्डवेअर ॲड्रेस फिरवतात ते नवीन उपकरणांसारखे दिसतात, त्यामुळे नेटवर्क त्यांना विसरून जाते.
- घर सोडल्यानंतरही प्रवेश तसाच राहतो. माजी रहिवाशाचा लॅपटॉप भाडेकरू करार संपल्यानंतरही कित्येक आठवडे कनेक्ट राहतो.
तुम्ही Hotels चालवत असाल आणि सर्व्हिस किंवा दीर्घकालीन मुक्कामाच्या अपार्टमेंट्समध्ये विस्तार करत असाल, तर तुम्हाला ही लक्षणे सर्वात आधी दीर्घकालीन मुक्कामाच्या मजल्यांवर आढळतील.
हॉटेल-शैलीतील अतिथी WiFi रहिवाशांसाठी का निकामी ठरते?
हॉटेल अतिथी WiFi मागील चार डिझाइन गृहीतके एकदा कोणीतरी तिथे राहायला आल्यावर निरुपयोगी ठरतात.
उपकरणांची संख्या वेगळी असते
हॉटेलचे अतिथी नेटवर्क हे एक किंवा दोन रात्रीसाठी फोन आणि लॅपटॉपच्या आसपास डिझाइन केलेले असते. त्याऐवजी वन-बेड अपार्टमेंटमधील उपकरणांची गणना करा: दोन फोन, दोन लॅपटॉप, एक स्मार्ट TV, एक स्ट्रीमिंग स्टिक, एक स्पीकर, एक व्हिडिओ डोअरबेल, एक थर्मोस्टॅट आणि एक प्रिंटर. कोणीही भेट देण्यापूर्वीच ही संख्या १० होते. त्यापैकी प्रत्येक उपकरणाला कनेक्ट करणे आवश्यक आहे आणि त्यापैकी बहुतांश उपकरणांवर टाईप करण्यासाठी स्क्रीन नसते.
हेडलेस उपकरणे captive portal वापरू शकत नाहीत
captive portal ब्राउझर विनंती थांबवून आणि लॉगइन पृष्ठ दाखवून कार्य करते. स्मार्ट स्पीकर कधीही ब्राउझर उघडत नाही, त्यामुळे त्याला कधीही ते पृष्ठ दिसत नाही आणि तो कधीही ऑथेंटिकेट होत नाही. यासाठीचा नेहमीचा तात्पुरता उपाय म्हणजे MAC ॲड्रेस नोंदणी, जिथे रहिवासी प्रत्येक उपकरणाचा हार्डवेअर ॲड्रेस फॉर्ममध्ये टाईप करतो. तो उपाय देखील निकामी ठरतो.
MAC रँडमायझेशन उपकरणाच्या मेमरीला कमकुवत करते
Apple ने iOS 14 मध्ये प्रति-नेटवर्क खाजगी ॲड्रेस सादर केले आणि Android 10 डीफॉल्टनुसार हार्डवेअर ॲड्रेस रँडमाईज करते. जे पोर्टल उपकरणांना MAC ॲड्रेसद्वारे लक्षात ठेवते, ते ॲड्रेस बदलताच त्यांना विसरून जाते. रहिवासी पुन्हा ऑथेंटिकेट करतात आणि तुमच्या हेल्पडेस्कला कॉल येतो.
क्लायंट आयसोलेशन घरगुती नेटवर्क अनुभवाला अवरोधित करते
गेस्ट नेटवर्क सामान्यतः क्लायंट्सना आयसोलेट करतात जेणेकरून अनोळखी लोक एकमेकांच्या डिव्हाइसेसपर्यंत पोहोचू शकणार नाहीत. हॉटेलच्या लॉबीमध्ये हे अगदी योग्य आहे. परंतु Chromecast आणि AirPlay हे मल्टिकास्ट DNS (mDNS, जे RFC 6762 मध्ये परिभाषित केले आहे) वापरून रिसीव्हर शोधतात, हा एक डिस्कव्हरी प्रोटोकॉल आहे जो केवळ एकाच नेटवर्क सेगमेंटमधील डिव्हाइसेस दरम्यान कार्य करतो. आयसोलेशन चालू असल्यास, कास्टिंग अयशस्वी होते. शेअर केलेल्या नेटवर्कवर आयसोलेशन बंद केल्यास प्रत्येक रहिवासी इतर प्रत्येक रहिवाशाचे डिव्हाइसेस पाहू शकतो.
शॉर्ट-स्टे ट्रस्ट हे चुकीचे ट्रस्ट मॉडेल आहे
हॉटेल WiFi एका मुक्कामासाठी डिव्हाइसवर विश्वास ठेवते आणि नंतर ते विसरून जाते. निवासी WiFi ला भाडेकरूच्या कालावधीसाठी, कधीकधी वर्षानुवर्षे, कुटुंबातील डिव्हाइसेसवर विश्वास ठेवावा लागतो. याशिवाय एका विशिष्ट तारखेला तो विश्वास रद्द देखील करावा लागतो. पोर्टल सेशन टाइमर यापैकी कोणताही नियम लागू करू शकत नाही.
तुमच्याकडे कोणते कारण आहे हे तुम्ही कसे शोधाल?
काहीही बदलण्यापूर्वी तक्रारीचे मूळ कारणाशी जुळवून घ्या. बहुतेक इमारतींमध्ये एकापेक्षा जास्त कारणे असतात.
| रहिवाशांनी नोंदवलेले लक्षण | सर्वात संभाव्य कारण | याची पुष्टी कशी करावी |
|---|---|---|
| स्मार्ट TV किंवा स्पीकर कनेक्ट होणार नाही | हेडलेस डिव्हाइसवरील Captive Portal | तुमच्या कंट्रोलर लॉगमध्ये डिव्हाइस कधी पोर्टल पेजवर पोहोचते का ते तपासा |
| फोन स्वतःचे Chromecast शोधू शकत नाही | क्लायंट आयसोलेशन mDNS ब्लॉक करत आहे | एकाच चाचणी SSID वर आयसोलेशन अक्षम करून कास्टिंगची चाचणी घ्या |
| कास्ट करताना रहिवाशांना शेजाऱ्यांची डिव्हाइसेस दिसतात | आयसोलेशन बंद असलेले शेअर केलेले फ्लॅट नेटवर्क | रहिवाशाच्या डिव्हाइसवरून mDNS जाहिरातींसाठी स्कॅन करा |
| प्रत्येक डिव्हाइसवर दररोज लॉगिन | शॉर्ट-स्टेसाठी तयार केलेला पोर्टल सेशन टाइमआउट | गेस्ट SSID वरील सेशन टाइमआउट वाचा |
| फोन अपडेटनंतर डिव्हाइसेस "विसरले" जातात | MAC-आधारित मेमरीच्या विरुद्ध MAC रँडमायझेशन | अपडेटपूर्वी आणि नंतरच्या डिव्हाइस हार्डवेअर पत्त्यांची तुलना करा |
| जुने रहिवासी अजूनही कनेक्ट होतात | भाडेकरू कालावधी संपणे आणि नेटवर्क ॲक्सेस यांच्यात कोणताही संबंध नाही | सध्याच्या भाडेकरूंच्या नोंदींच्या विरूद्ध सक्रिय क्रेडेन्शियल्सचे ऑडिट करा |
जर पहिल्या दोन ओळी तुमच्या इमारतीचे वर्णन करत असतील, तर सेशन टाइमआउट निश्चित केल्याने मदत होणार नाही. तुम्हाला एका वेगळ्या ऑथेंटिकेशन मॉडेलची गरज आहे, ट्यून केलेल्या पोर्टलची नाही.
कोणते ऑथेंटिकेशन मॉडेल रहिवाशांसाठी योग्य आहे?
खालील तक्ता इमारती प्रत्यक्षात वापरत असलेल्या चार पर्यायांची तुलना करतो.
| दृष्टिकोन | ऑनबोर्डिंग | हेडलेस डिव्हाइसेस | कास्टिंग आणि स्मार्ट होम | एका कुटुंबाचे ॲक्सेस रद्द करणे | यासाठी सर्वात योग्य |
|---|---|---|---|---|---|
| Captive Portal (हॉटेल पॅटर्न) | प्रत्येक डिव्हाइसवर ब्राउझर लॉगिन, टाइमआउट झाल्यावर पुन्हा करावे लागते | मॅन्युअल MAC नोंदणीशिवाय अयशस्वी | क्लायंट आयसोलेशनद्वारे ब्लॉक केलेले | सेशन्सची मुदत संपण्याची प्रतीक्षा करा | हॉटेलचे पाहुणे, खरेदीदार, चाहते, प्रवासी |
| प्रति इमारत एक शेअर केलेला पासफ्रेज | प्रत्येकासाठी एकच पासफ्रेज | कनेक्ट | काम करते, परंतु प्रत्येक रहिवासी प्रत्येक डिव्हाइस पाहू शकतो | संपूर्ण इमारतीचा पासफ्रेज बदला | कोणतीही मल्टी-टेनंट इमारत नाही |
| प्रति कुटुंब iPSK | प्रति अपार्टमेंट एक युनिक पासफ्रेज | कनेक्ट | केवळ कुटुंबाच्या सेगमेंटमध्येच काम करते | एक की डिलीट करा | BTR, विद्यार्थी वसतिगृहे, MDU, दीर्घकाळ मुक्काम |
iPSK (identity pre-shared key) सिंगल WPA2-Personal नेटवर्क चालवते जिथे प्रत्येक कुटुंबाला स्वतःचा पासफ्रेज मिळतो. जेव्हा एखादे उपकरण जोडले जाते, तेव्हा RADIUS सर्व्हर (क्रेडेंशियल तपासणारी प्रमाणीकरण सेवा) ते कोणत्या की द्वारे जोडले गेले आहे ते ओळखतो. त्यानंतर नेटवर्क त्या उपकरणाला त्या कुटुंबाच्या VLAN (एक व्हर्च्युअल नेटवर्क सेगमेंट) मध्ये ठेवते. रहिवाशाच्या मालकीचे प्रत्येक उपकरण, हेडलेस असो वा नसो, आधीपासून माहित असलेल्या पासफ्रेजसह एकदाच जोडले जाते.
याचा परिणाम म्हणजे प्रत्येक अपार्टमेंटसाठी एक खाजगी नेटवर्क बबल तयार होतो. रहिवाशाचा फोन त्यांचे स्वतःचे Chromecast शोधू शकतो कारण दोन्ही एकाच सेगमेंटमध्ये असतात. हे शेजारच्या फ्लॅटमधील उपकरणे पाहू शकत नाही कारण त्या कुटुंबाकडे वेगळी की असते आणि ते वेगळ्या सेगमेंटमध्ये असतात.
IEEE 802.1X हे प्रति व्यक्ती अधिक मजबूत आहे, परंतु बहुतेक स्मार्ट टीव्ही, स्पीकर्स आणि थर्मोस्टॅट्स याचा वापर करू शकत नाहीत. हे कर्मचारी नेटवर्कसाठी राखून ठेवा.
तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?
आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.
तुम्ही Cisco Meraki, HPE Aruba, Ruckus आणि इतर हार्डवेअरवर हे कसे दुरुस्त करता?
तुम्हाला नवीन ॲक्सेस पॉइंट्सची आवश्यकता नाही. प्रत्येक प्रमुख विक्रेता स्वतःच्या नावाखाली प्रति-की प्रमाणीकरणाला सपोर्ट करतो:
- Cisco Meraki: Identity PSK (iPSK)
- HPE Aruba: MPSK (Multiple Pre-Shared Key)
- Ruckus: DPSK (Dynamic Pre-Shared Key)
- Juniper Mist: Multi PSK
- Ubiquiti UniFi: Private Pre-Shared Keys
- Cambium: ePSK
- Extreme: PPSK (Private Pre-Shared Key)
- Fortinet: MPSK
स्विच करण्यापूर्वी तुमच्या विक्रेत्याच्या दस्तऐवजीकरणात दोन गोष्टी तपासा. पहिली, तुमच्या कंट्रोलर व्हर्जनवर प्रति SSID की च्या कमाल संख्येची पुष्टी करा. दुसरी, प्रति-की प्रमाणीकरणासह WPA3-Personal ला सपोर्ट आहे की नाही याची पुष्टी करा, कारण अनेक अंमलबजावणी अजूनही WPA2-Personal वर चालतात.
Purple चे Multi-Tenant WiFi त्या हार्डवेअरच्या वर क्लाउड ओव्हरले म्हणून चालते, त्यामुळे कोणतेही रिप आणि रिप्लेस (हार्डवेअर बदलण्याची) गरज नसते. Purple क्लाउड RADIUS सेवा प्रदान करते जी प्रत्येक की ला तिच्या संबंधित कुटुंबाशी जोडते. तुम्ही एकाच स्क्रीनवरून प्रत्येक इमारतीच्या की व्यवस्थापित करू शकता. Purple कडे ISO 27001 प्रमाणपत्र आहे आणि ते GDPR सुसंगत आहे, आणि हे प्लॅटफॉर्म ८०,०००+ हून अधिक लाइव्ह ठिकाणी चालते (Purple चा स्वतःचा डेटा).
अभ्यागतांसाठी तुमचे गेस्ट नेटवर्क ठेवा. Purple चे Guest WiFi कनेक्ट होणाऱ्या प्रत्येक अभ्यागतासाठी WiFi Visitors रेकॉर्ड तयार करते. Purple च्या WiFi Visitors सपोर्ट आर्टिकल नुसार, त्या रेकॉर्डमध्ये भेट दिलेली ठिकाणे, भेटींची संख्या आणि कनेक्शन पद्धत समाविष्ट असते. हे लॉबी किंवा तळमजल्यावरील कॅफेसाठी योग्य आहे, रहिवाशाच्या घरगुती कनेक्शनसाठी नाही.
व्यावहारिक उदाहरण: हॉटेलमध्ये दीर्घकाळ मुक्कामासाठी एक मजला जोडणे
परिस्थिती. एका १८० खोल्यांच्या सिटी हॉटेलने एक मजला १ ते ६ महिन्यांच्या मुक्कामासाठी ४० सर्व्हिस अपार्टमेंट्समध्ये रूपांतरित केला. दीर्घकाळ मुक्काम करणारे पाहुणे विद्यमान गेस्ट SSID वापरत होते, ज्यामध्ये captive portal, क्लायंट आयसोलेशन आणि २४ तासांची सेशन टाईमआउट मर्यादा होती.
काय केले गेले. हॉटेलने शॉर्ट-स्टे रूम्स आणि लॉबीसाठी पोर्टल SSID कायम ठेवले. त्यांनी लाँग-स्टे फ्लोअरसाठी 40 की असलेले एक iPSK SSID जोडले, ज्यातील प्रत्येक की स्वतःच्या VLAN शी मॅप केली होती. चेक-इन करताना की जारी केल्या गेल्या आणि चेक-आउट करताना डिलीट केल्या गेल्या.
परिणाम. लाँग-स्टे पाहुण्यांचे लॉगिन दर आठवड्याला सातवरून कमी होऊन आगमनाच्या वेळी फक्त एक झाले. स्मार्ट टीव्ही आणि कास्टिंग डिव्हाइसेस पहिल्याच प्रयत्नात जोडले गेले कारण त्यांना आता पोर्टलचा सामना करावा लागला नाही. चेक-आउटच्या वेळी, एक की डिलीट केल्याने त्या अपार्टमेंटचे कनेक्ट केलेले प्रत्येक डिव्हाइस काढून टाकले गेले.
व्यावहारिक उदाहरण: युनिव्हर्सिटी हॉल्सने MAC नोंदणी बदलली
परिस्थिती. एक सरकारी युनिव्हर्सिटी 600 खाटांचे निवासी हॉल एका कॅप्टिव्ह पोर्टलवर चालवत होती. विद्यार्थी गेम कन्सोल आणि स्मार्ट स्पीकर्सची नोंदणी वेब फॉर्ममध्ये प्रत्येक MAC ॲड्रेस टाईप करून करत असत. फोनवरील यादृच्छिक ॲड्रेसमुळे प्रत्येक टर्ममध्ये पुन्हा नोंदणी करावी लागत असे.
काय केले गेले. IT विभागाने विद्यमान ॲक्सेस पॉइंट्सवर प्रत्येक स्टडी बेडरूमसाठी एक iPSK की जारी केली. प्रत्येक विद्यार्थ्याला त्यांच्या रूम अलॉटमेंटसह त्यांची की मिळाली. की राहण्याच्या कराराच्या समाप्ती तारखेशी लिंक केल्या गेल्या होत्या.
परिणाम. मॅन्युअल MAC नोंदणी शून्यावर आली, कारण कन्सोल आणि स्पीकर्स आता पासफ्रेजसह जोडले जातात. शैक्षणिक वर्षाच्या शेवटी, IT ने वैयक्तिक डिव्हाइस रेकॉर्ड्स शोधण्याऐवजी एकाच बॅचमध्ये सर्व 600 की रद्द केल्या.
हे पुन्हा घडण्यापासून तुम्ही कसे रोखू शकता?
निवासी नेटवर्कची रचना भाडेकरूंच्या कालावधीनुसार करा, तात्पुरत्या भेटीनुसार नाही.
- प्रेक्षकांनुसार नेटवर्क वेगळे करा. अभ्यागतांसाठी पोर्टलसह गेस्ट SSID आणि रहिवाशांसाठी iPSK SSID चालवा. SSID ची संख्या कमी ठेवा, कारण प्रत्येक अतिरिक्त SSID बीकन ट्रॅफिक वाढवते आणि एअरटाइम वापरते.
- कीज् जोडणे, बदलणे आणि सोडणाऱ्यांशी लिंक करा. रहिवासी आल्यावर की जारी करा, रहिवासी युनिट बदलतो तेव्हा ती पुन्हा सोपवा आणि भाडेकरू कालावधी संपण्याच्या तारखेला ती रद्द करा. Purple चे Multi-Tenant WiFi या लाइफसायकलचे केंद्रीय पद्धतीने व्यवस्थापन करते.
- क्षमतेचे नियोजन अपार्टमेंटनुसार करा, डोक्यावर नाही. रात्रीच्या पीक अवर्समधील स्ट्रीमिंगसह, प्रत्येक युनिटचा आकार त्याच्या संपूर्ण डिव्हाइस संख्येनुसार ठरवा.
- डेटा मॉडेल्स वेगळे ठेवा. गेस्ट WiFi चे अस्तित्व काही प्रमाणात जागरूक संमतीने फर्स्ट-पार्टी डेटा तयार करण्यासाठी असते. निवासी WiFi ही एक सेवा आहे जी तुम्ही भाडेकरू करारांतर्गत प्रदान करता, त्यामुळे त्यावर मार्केटिंग डेटा गोळा करू नका. जर तुम्हाला सामायिक जागा कशा वापरल्या जातात हे समजून घ्यायचे असेल, तर Presence analytics vs engagement analytics वाचा. जर तुम्ही HPE Aruba वापरत असाल, तर HPE Aruba Central presence analytics: setup, exports and limits वाचा.
- मिश्र-वापर असलेल्या साइट्सवरही हाच पॅटर्न लागू करा. तळमजल्यावर Retail युनिट्स असलेली किंवा Healthcare कॅम्पसवर कर्मचारी निवासस्थान असलेली इमारत असल्यास, लोकांसाठी पोर्टल आणि तिथे राहणाऱ्या लोकांसाठी iPSK ची आवश्यकता असते.
वारंवार विचारले जाणारे प्रश्न
मी रहिवाशांसाठी कॅप्टिव्ह पोर्टल वापरू शकतो का?
नाही, मुख्य निवासी नेटवर्क म्हणून नाही. Captive Portal ला प्रत्येक डिव्हाइसवर ब्राउझरची आवश्यकता असते, आणि स्मार्ट टीव्ही, स्पीकर्स आणि थर्मोस्टॅट्समध्ये ब्राउझर नसतो. पोर्टल्स सेशन्स देखील एक्स्पायर करतात आणि ज्यांचे हार्डवेअर ॲड्रेस रोटेट होतात अशा डिव्हाइसेसना विसरतात. व्हिजिटर्स आणि कमी कालावधीसाठी येणाऱ्या पाहुण्यांसाठी पोर्टल ठेवा. रहिवाशांना प्रति-घर iPSK की द्या जेणेकरून प्रत्येक डिव्हाइस एकदाच कनेक्ट होईल आणि भाडेकरू कालावधी संपेपर्यंत कनेक्ट राहील.
मी आधीपासून मालकी हक्क असलेल्या ॲक्सेस पॉइंट्सवर iPSK काम करेल का?
होय, जर तुम्ही प्रमुख वेंडरचे सध्याचे कंट्रोलर चालवत असाल तर. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet हे सर्व त्यांच्या स्वतःच्या वैशिष्ट्यांच्या नावांतर्गत प्रति-की ऑथेंटिकेशनला सपोर्ट करतात. तुमच्या कंट्रोलर व्हर्जनवर प्रति SSID कमाल की तपासण्यासाठी तुमच्या वेंडरचे डॉक्युमेंटेशन पहा. Purple त्या हार्डवेअरवर क्लाउड ओव्हरले म्हणून चालते, त्यामुळे रहिवाशांना iPSK वर शिफ्ट करण्यासाठी तुम्हाला ॲक्सेस पॉइंट्स बदलण्याची गरज नाही.
गेस्ट WiFi आणि रहिवासी WiFi एकाच ॲक्सेस पॉइंट्सवर चालू शकतात का?
होय. त्यांना एकाच ॲक्सेस पॉइंट्सवर स्वतंत्र SSIDs म्हणून चालवा, जे प्रत्येक स्वतःच्या VLANs ला मॅप केलेले असतील. व्हिजिटर्सना त्यांचे captive portal असलेले गेस्ट नेटवर्क दिसेल आणि रहिवासी त्यांच्या कौटुंबिक कीसह iPSK नेटवर्कमध्ये सामील होतील. एकूण SSID संख्या कमी ठेवा, कारण प्रत्येक अतिरिक्त SSID बीकन ट्रॅफिक वाढवते जे ते ब्रॉडकास्ट करणाऱ्या प्रत्येक ॲक्सेस पॉइंटवरील एअरटाइम वापरते.
रहिवासी घर सोडून गेल्यास त्यांच्या डिव्हाइसेसचे काय होते?
तुम्ही त्यांची की रद्द करता आणि ती की वापरणाऱ्या प्रत्येक डिव्हाइसचा ॲक्सेस बंद होतो. प्रत्येक कुटुंबाकडे स्वतःचा पासफ्रेज असल्याने, एकाच डिलीशनमुळे फोन, लॅपटॉप, टीव्ही आणि स्पीकर एकत्र काढून टाकले जातात, ज्याचा इतर कोणत्याही रहिवाशावर परिणाम होत नाही. की रद्द करणे हे भाडेकरू कराराच्या शेवटच्या तारखेशी लिंक करा जेणेकरून कोणीतरी पासवर्ड बदलण्याची वाट न पाहता, करार संपेल त्याच दिवशी ॲक्सेस संपेल.
iPSK हे 802.1X इतके सुरक्षित आहे का?
नाही, परंतु निवासी डिव्हाइसेससाठी हे योग्य नियंत्रण आहे. IEEE 802.1X प्रत्येक व्यक्तीला स्वतंत्र क्रेडेंशियल देते, जे कर्मचाऱ्यांच्या लॅपटॉपसाठी योग्य आहे. बहुतेक स्मार्ट टीव्ही आणि स्पीकर्स याचा वापर करू शकत नाहीत, त्यामुळे हे अपार्टमेंट्समध्ये अयशस्वी ठरते. iPSK प्रत्येक कुटुंबाला एक युनिक की देते आणि त्याला स्वतःच्या VLAN मध्ये आयसोलेट करते, त्यामुळे की लीक झाल्यास संपूर्ण इमारत नाही तर फक्त एक अपार्टमेंट उघडे पडते. कर्मचाऱ्यांसाठी 802.1X आणि रहिवाशांसाठी iPSK वापरा.
निवासी WiFi ला GDPR वेगळ्या प्रकारे कसा लागू होतो?
UK GDPR अंतर्गत, रहिवाशांचे कनेक्शन ही एक सेवा आहे जी तुम्ही भाडेकरू करारांतर्गत प्रदान करता, त्यामुळे कायदेशीर आधार बहुधा Article 6(1)(b) अंतर्गत करार असेल, मार्केटिंग संमती नाही. गेस्ट WiFi सहसा ऑप्ट-इनसह मार्केटिंग डेटा गोळा करते. दोन्ही स्वतंत्र ठेवा: निवासी नेटवर्कवर मार्केटिंग कॅप्चर चालवू नका. Purple हे ISO 27001 सर्टिफाइड आणि GDPR सुसंगत आहे, आणि त्या आधारावर रहिवासी नेटवर्क डेटावर प्रक्रिया करते.
पोर्टलवरून iPSK कडे शिफ्ट होण्यासाठी किती प्रयत्न करावे लागतील?
हा कॉन्फिगरेशनमधील बदल आहे, हार्डवेअर प्रोजेक्ट नाही. तुम्ही तुमच्या सध्याच्या कंट्रोलरवर iPSK SSID तयार करता, त्याला Purple च्या क्लाउड RADIUS सारख्या RADIUS सेवेशी जोडता आणि कीज (keys) घरगुती VLANs शी मॅप करता. सर्वात मोठे काम ऑपरेशनल आहे: प्रवेश करताना कीज जारी करणे आणि भाडेकरू कालावधी संपण्याच्या तारखेशी त्या रद्द करण्याची प्रक्रिया जोडणे. बदल करताना पोर्टल आणि iPSK नेटवर्क सोबत चालवा जेणेकरून कोणत्याही रहिवाशाचा ॲक्सेस बंद होणार नाही.
महत्वाच्या व्याख्या
Captive portal
एक वेब लॉगिन पेज जे ओपन किंवा अतिथी नेटवर्कवर डिव्हाइसच्या पहिल्या HTTP विनंतीला अडवते आणि जोपर्यंत वापरकर्ता ऑथेंटिकेट करत नाही किंवा अटी स्वीकारत नाही तोपर्यंत त्याला रीडायरेक्ट करते. हे ब्राउझरवर अवलंबून असते आणि कोणत्याही IEEE 802.11 ऑथेंटिकेशन पद्धतीचा भाग नाही.
तुम्हाला हे प्रत्येक हॉटेल-स्टाईल अतिथी SSID वर पाहायला मिळते. हे रहिवाशांसाठी अयशस्वी ठरते कारण स्क्रीन नसलेले डिव्हाइसेस कधीही ब्राउझर उघडू शकत नाहीत आणि त्याचे सेशन टाइमर वारंवार लॉगिन करण्यास भाग पाडतात.
iPSK (identity pre-shared key)
एक विक्रेता अंमलबजावणी जी एका WPA2-Personal SSID वर अनेक युनिक पासफ्रेजेस जारी करते. IEEE 802.11 फोर-वे हँडशेक दरम्यान डिव्हाइसने कोणती की वापरली हे ॲक्सेस पॉइंट तपासतो, त्यानंतर एक RADIUS सर्व्हर ती की एका घराशी आणि त्याच्या VLAN शी मॅप करतो.
या मार्गदर्शकामध्ये हे शिफारस केलेले रहिवासी मॉडेल आहे. विक्रेते याला वेगवेगळी नावे देतात: Cisco Meraki वर Identity PSK, HPE Aruba आणि Fortinet वर MPSK, Ruckus वर DPSK, Extreme वर PPSK.
RADIUS
रिमोट ऑथेंटिकेशन डायल-इन युझर सर्व्हिस, IETF RFC 2865 मध्ये निर्दिष्ट केली आहे. एक क्लायंट-सर्व्हर प्रोटोकॉल ज्याद्वारे ॲक्सेस पॉइंट केंद्रीय सर्व्हरला डिव्हाइस ऑथेंटिकेट करण्यास सांगतो आणि असाइन करण्यासाठी VLAN सारखे गुणधर्म परत करतो.
iPSK उपयोजनामध्ये RADIUS सेवा डिव्हाइसने कोणती घरगुती की वापरली हे ओळखते. Purple हे क्लाउड RADIUS सेवा म्हणून प्रदान करते, त्यामुळे ऑन-साइट सर्व्हरची आवश्यकता नसते.
VLAN
एक व्हर्च्युअल लोकल एरिया नेटवर्क, जे IEEE 802.1Q द्वारे परिभाषित केले आहे, जे इथरनेट फ्रेम्स टॅग करते जेणेकरून अनेक लॉजिकली वेगळे नेटवर्क विभाग समान फिजिकल स्विचेस आणि ॲक्सेस पॉइंट्स शेअर करतात.
प्रत्येक घरगुती की स्वतःच्या VLAN वर मॅप करते. तो विभाग रहिवाशांना शेजारच्या अपार्टमेंटला न दिसता स्वतःच्या टीव्हीवर कास्ट करण्याची परवानगी देतो.
Client isolation
अ‍ॅक्सेस पॉईंटची अशी सेटिंग जी एकाच SSID वरील वायरलेस क्लायंट्समधील थेट लेअर 2 ट्रॅफिक ब्लॉक करते, ज्यामुळे डिव्हाइसेस गेटवेपर्यंत पोहोचू शकतात परंतु एकमेकांशी कनेक्ट होऊ शकत नाहीत.
हॉटेलच्या लॉबी नेटवर्कवर हे योग्य आहे. रहिवासी नेटवर्कवर हे कास्टिंग ब्लॉक करते, आणि शेअर केलेल्या फ्लॅट नेटवर्कवर हे बंद केल्याने प्रत्येक रहिवाशाची डिव्हाइसेस उघडी पडतात.
Multicast DNS (mDNS)
शून्य-कॉन्फिगरेशन नेम रिझोल्यूशन आणि सर्व्हिस डिस्कव्हरी प्रोटोकॉल जो IETF RFC 6762 मध्ये निर्दिष्ट केला आहे. हा लिंक-लोकल मल्टिकास्ट पत्त्यावर क्वेरी पाठवतो, ज्यामुळे तो फक्त त्याच नेटवर्क सेगमेंटवरील डिव्हाइसेसपर्यंत पोहोचतो.
Chromecast आणि AirPlay रिसीव्हर्स शोधण्यासाठी यावर अवलंबून असतात. रहिवाशाचा फोन आणि टीव्ही वेगवेगळ्या सेगमेंटमध्ये विभागणारी किंवा त्यांना आयसोलेट करणारी कोणतीही डिझाइन कास्टिंग खंडित करते.
MAC randomisation
एक गोपनीयता वैशिष्ट्य ज्यामध्ये डिव्हाइस त्याच्या फॅक्टरी पत्त्याऐवजी प्रति नेटवर्क किंवा वेळेनुसार वेगळा हार्डवेअर (MAC) पत्ता दर्शवते. Apple ने iOS 14 मध्ये प्रति-नेटवर्क खाजगी पत्ते सादर केले आणि Android 10 डीफॉल्टनुसार रँडमाइज करते.
हार्डवेअर पत्त्याद्वारे डिव्हाइसेस लक्षात ठेवणारे पोर्टल्स आणि MAC रजिस्ट्रेशन फॉर्म्स पत्ता बदलल्यावर ते डिव्हाइसेस विसरतात, ज्यामुळे वारंवार लॉगिन करावे लागते आणि हेल्पडेस्क कॉल्स वाढतात.
IEEE 802.1X
पोर्ट-आधारित नेटवर्क अ‍ॅक्सेस कंट्रोलसाठी IEEE मानक. हे डिव्हाइस, अ‍ॅक्सेस पॉईंट आणि RADIUS सर्व्हर दरम्यान Extensible Authentication Protocol (EAP) एक्सचेंज वाहून नेते, ज्यामुळे प्रत्येक व्यक्तीला वैयक्तिक क्रेडेंशियल किंवा सर्टिफिकेट मिळते.
हे प्रति व्यक्ती अधिक मजबूत आहे आणि स्टाफ WiFi तसेच व्यवस्थापित लॅपटॉपसाठी योग्य आहे. बहुतेक स्मार्ट टीव्ही, स्पीकर्स आणि थर्मोस्टॅट्स हे वापरू शकत नाहीत, त्यामुळे अपार्टमेंट्ससाठी हे चुकीचे मॉडेल आहे.
WPA2-Personal and WPA3-Personal
IEEE 802.11 मानकावर आधारित प्री-शेअर्ड की सुरक्षा मोड्स. WPA2-Personal फोर-वे हँडशेकद्वारे पासफ्रेजमधून एन्क्रिप्शन की मिळवते, तर WPA3-Personal याला Simultaneous Authentication of Equals (SAE) ने बदलते.
अनेक प्रति-की अंमलबजावणी अजूनही WPA2-Personal वर चालतात. तुम्ही स्विच करण्यापूर्वी WPA3-Personal सपोर्टसाठी तुमच्या वेंडरचे दस्तऐवज तपासा.
Headless device
स्क्रीन किंवा ब्राउझर नसलेले कनेक्ट केलेले डिव्हाइस, जसे की स्मार्ट स्पीकर, थर्मोस्टॅट, स्ट्रीमिंग स्टिक किंवा गेम्स कन्सोल. हे स्टोअर केलेल्या पासफ्रेजसह नेटवर्कमध्ये सामील होऊ शकते परंतु वेब लॉगिन पूर्ण करू शकत नाही.
कोणीही भेट देण्यापूर्वी एका वन-बेड अपार्टमेंटमध्ये 10 डिव्हाइसेस असू शकतात आणि बहुतेक हेडलेस असतात. हेच मुख्य कारण आहे ज्यामुळे कॅप्टिव्ह पोर्टल्स रहिवाशांसाठी अपयशी ठरतात.
UK GDPR Article 6(1)(b)
UK GDPR अंतर्गत कायदेशीर आधार जो व्यक्तीसोबतच्या कराराच्या पूर्ततेसाठी आवश्यक असेल तेथे वैयक्तिक डेटावर प्रक्रिया करण्याची परवानगी देतो, जो Article 6(1)(a) अंतर्गत संमतीपेक्षा वेगळा आहे.
रहिवाशाचे कनेक्शन ही भाडेकरू करारांतर्गत एक सेवा आहे, त्यामुळे करार हाच संभाव्य कायदेशीर आधार आहे. म्हणूनच तुम्ही मार्केटिंग कॅप्चर आणि ऑप्ट-इन्स फक्त गेस्ट नेटवर्कवर ठेवता.
सोडवलेली उदाहरणे
एक १८० खोल्यांचे शहर हॉटेल एका मजल्याचे १ ते ६ महिन्यांच्या वास्तव्यासाठी ४० सर्व्हिस अपार्टमेंट्समध्ये रूपांतरित करते. दीर्घकाळ राहणारे अतिथी विद्यमान अतिथी SSID वापरत आहेत, ज्यामध्ये captive portal, क्लायंट आयसोलेशन आणि २४ तासांचे सेशन टाईमआऊट चालू आहे. ते रोजच्या लॉगिनबद्दल आणि कनेक्ट न होणाऱ्या स्मार्ट टीव्हीबद्दल तक्रार करतात. हॉटेलने काय बदलले पाहिजे?
हॉटेलने अल्प-मुदतीच्या खोल्यांसाठी आणि लॉबीसाठी captive portal SSID चालू ठेवला आणि दीर्घकाळ राहणाऱ्यांच्या मजल्यासाठी एक iPSK SSID जोडला. त्यांनी ४० की तयार केल्या, प्रत्येक की स्वतःच्या VLAN ला मॅप केली, जी चेक-इनच्या वेळी दिली जाते आणि चेक-आऊटच्या वेळी डिलीट केली जाते. दीर्घकाळ राहणाऱ्या अतिथींचे लॉगिन दर आठवड्याला सातवरून थेट आगमनाच्या वेळी एकावर आले. स्मार्ट टीव्ही आणि कास्टिंग डिव्हाइसेस पहिल्याच प्रयत्नात जोडले गेले कारण त्यांना आता पोर्टलचा सामना करावा लागला नाही. चेक-आऊटच्या वेळी, एका की डिलीट केल्याने त्या अपार्टमेंटचे कनेक्ट केलेले प्रत्येक डिव्हाइस काढून टाकले गेले. हा विभाग यशस्वी ठरतो कारण अल्प-मुदतीचे अतिथी अजूनही पोर्टलसाठी योग्य आहेत, तर दीर्घकाळ राहणाऱ्या अतिथींना संपूर्ण वास्तव्यादरम्यान टिकणारा आणि एका निश्चित तारखेला संपणारा विश्वास हवा असतो.
एक सरकारी विद्यापीठ captive portal वर ६०० खाटांचे वसतिगृह चालवते. विद्यार्थी प्रत्येक MAC ॲड्रेस एका वेब फॉर्ममध्ये टाईप करून गेम कन्सोल आणि स्मार्ट स्पीकर्सची नोंदणी करतात आणि फोनवरील रँडमाइज्ड ॲड्रेसमुळे दर टर्मला पुन्हा नोंदणी करावी लागते. IT ने नवीन हार्डवेअरशिवाय हे कसे दुरुस्त करावे?
IT ने विद्यमान ॲक्सेस पॉइंट्सवर प्रति-अभ्यास खोली एक iPSK की जारी केली. प्रत्येक विद्यार्थ्याला त्यांच्या खोलीच्या वाटपासोबत त्यांची की मिळाली आणि प्रत्येक की निवास कराराच्या समाप्तीच्या तारखेशी जोडली गेली. मॅन्युअल MAC नोंदणी शून्यावर आली, कारण कन्सोल आणि स्पीकर्स आता त्यांना आधीपासून माहित असलेल्या पासफ्रेजसह जोडले जातात. फोनच्या रँडमाइज्ड ॲड्रेसमुळे आता फरक पडत नाही, कारण नेटवर्क हार्डवेअर ॲड्रेसऐवजी की ओळखते. शैक्षणिक वर्षाच्या शेवटी, IT ने वैयक्तिक डिव्हाइस रेकॉर्ड शोधण्याऐवजी एकाच बॅचमध्ये सर्व ६०० की रद्द केल्या. या बदलामुळे नोंदणी फॉर्म आणि टर्मच्या शेवटी होणारी स्वच्छता एकाच हालचालीत दूर झाली.
वारंवार विचारले जाणारे प्रश्न
मी रहिवाशांसाठी Captive Portal वापरू शकतो का?
नाही, मुख्य रहिवासी नेटवर्क म्हणून नाही. Captive Portal साठी प्रत्येक डिव्हाइसवर ब्राउझर असणे आवश्यक आहे, आणि स्मार्ट टीव्ही, स्पीकर्स आणि थर्मोस्टॅट्समध्ये तो नसतो. पोर्टल्स सेशन्स संपवतात आणि ज्या डिव्हाइसेसचे हार्डवेअर पत्ते बदलतात त्यांना विसरतात. पाहुणे आणि अल्पमुदतीच्या पाहुण्यांसाठी पोर्टल ठेवा. रहिवाशांना प्रति-घरगुती iPSK की द्या जेणेकरून प्रत्येक डिव्हाइस एकदाच जोडले जाईल आणि भाडेकरू कराराच्या कालावधीसाठी कनेक्टेड राहील.
iPSK माझ्याकडे आधीपासून असलेल्या ॲक्सेस पॉइंट्सवर काम करेल का?
होय, जर तुम्ही प्रमुख व्हेंडरचे सध्याचे कंट्रोलर चालवत असाल. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet हे सर्व त्यांच्या स्वतःच्या फीचर नावांनुसार प्रति-की प्रमाणीकरणाला (per-key authentication) सपोर्ट करतात. तुमच्या कंट्रोलर व्हर्जनवर प्रति SSID जास्तीत जास्त कीज मिळवण्यासाठी तुमच्या व्हेंडरचे दस्तऐवज तपासा. Purple त्या हार्डवेअरवर क्लाउड ओव्हरले म्हणून चालते, त्यामुळे रहिवाशांना iPSK वर स्थलांतरित करण्यासाठी तुम्हाला ॲक्सेस पॉइंट्स बदलण्याची गरज नाही.
गेस्ट WiFi आणि रहिवासी WiFi एकाच ॲक्सेस पॉइंट्सवर चालवता येतील का?
होय. त्यांना एकाच ॲक्सेस पॉइंट्सवर स्वतंत्र SSID म्हणून चालवा, जे प्रत्येक स्वतःच्या VLANs शी मॅप केलेले असतील. अभ्यागतांना त्यांच्या Captive Portal सह गेस्ट नेटवर्क दिसते आणि रहिवासी त्यांच्या कौटुंबिक कीसह iPSK नेटवर्कमध्ये सामील होतात. एकूण SSID संख्या कमी ठेवा, कारण प्रत्येक अतिरिक्त SSID बीकन ट्रॅफिक वाढवते जे ब्रॉडकास्ट करणाऱ्या प्रत्येक ॲक्सेस पॉइंटवरील एअरटाइम वापरते.
जेव्हा एखादा रहिवासी घर सोडून जातो तेव्हा त्यांच्या डिव्हाइसेसचे काय होते?
तुम्ही त्यांची की रद्द करता आणि ती वापरणाऱ्या प्रत्येक डिव्हाइसचा ॲक्सेस निघून जातो. प्रत्येक कुटुंबाकडे स्वतःचा पासफ्रेज असल्याने, एक डिलीट केल्याने इतर कोणत्याही रहिवाशांना स्पर्श न करता फोन, लॅपटॉप, टीव्ही आणि स्पीकर एकत्र काढून टाकले जातात. की रद्द करण्याची प्रक्रिया भाडेकरू करार संपण्याच्या तारखेशी जोडा जेणेकरून एखाद्याने पासवर्ड बदलण्याचे लक्षात ठेवण्याऐवजी करार संपेल त्या दिवशी ॲक्सेस समाप्त होईल.
iPSK हे 802.1X इतकेच सुरक्षित आहे का?
नाही, परंतु निवासी डिव्हाइसेससाठी हे योग्य नियंत्रण आहे. IEEE 802.1X प्रत्येक व्यक्तीला वैयक्तिक क्रेडेंशियल देते, जे कर्मचाऱ्यांच्या लॅपटॉपसाठी योग्य आहे. बहुतेक स्मार्ट टीव्ही आणि स्पीकर हे वापरू शकत नाहीत, त्यामुळे हे अपार्टमेंट्समध्ये अपयशी ठरते. iPSK प्रत्येक कुटुंबाला एक युनिक की देते आणि त्याला स्वतःच्या VLAN मध्ये आयसोलेट करते, ज्यामुळे लीक झालेली की एका अपार्टमेंटला उघड करते, संपूर्ण इमारतीला नाही. कर्मचाऱ्यांसाठी 802.1X आणि रहिवाशांसाठी iPSK वापरा.
GDPR रहिवासी WiFi ला कशा प्रकारे वेगळे लागू होते?
UK GDPR अंतर्गत, रहिवाशांचे कनेक्शन ही एक सेवा आहे जी तुम्ही भाडेकरू करारांतर्गत प्रदान करता, त्यामुळे कायदेशीर आधार हा कलम 6(1)(b) अंतर्गत करार असण्याची दाट शक्यता आहे, मार्केटिंग संमती नाही. गेस्ट WiFi सामान्यतः ऑप्ट-इन्ससह मार्केटिंग डेटा गोळा करते. दोन्ही स्वतंत्र ठेवा: रहिवासी नेटवर्कवर मार्केटिंग कॅप्चर चालवू नका. Purple हे ISO 27001 प्रमाणित आणि GDPR सुसंगत आहे, आणि त्या आधारावर रहिवासी नेटवर्क डेटावर प्रक्रिया करते.
पोर्टलवरून iPSK वर जाण्यासाठी किती प्रयत्नांची आवश्यकता असते?
हा कॉन्फिगरेशनमधील बदल आहे, हार्डवेअर प्रोजेक्ट नाही. तुम्ही तुमच्या अस्तित्त्वात असलेल्या कंट्रोलरवर एक iPSK SSID तयार करता, त्याला Purple च्या क्लाउड RADIUS सारख्या RADIUS सेवेशी कनेक्ट करता आणि कीज कौटुंबिक VLANs शी मॅप करता. मोठे काम ऑपरेशनल आहे: घर बदलून येताना की देणे आणि भाडेकरू करार संपण्याच्या तारखांशी की रद्द करण्याची प्रक्रिया जोडणे. बदल करत असताना पोर्टल आणि iPSK नेटवर्क शेजारी शेजारी चालवा जेणेकरून कोणत्याही रहिवाशाचा ॲक्सेस जाणार नाही.
या मालिकेमध्ये पुढे वाचा
बहुभाडेकरू कार्यालयीन इमारतींसाठी WiFi नेटवर्कचे डिझाइन करणे
हे मार्गदर्शक IT व्यवस्थापक, नेटवर्क आर्किटेक्ट आणि CTOs ना बहुभाडेकरू कार्यालयीन इमारतींमध्ये स्केलेबल, सुरक्षित आणि वेगळे केलेले WiFi नेटवर्क डिझाइन करण्यासाठी विक्रेता-तटस्थ ब्लू प्रिंट प्रदान करते. यामध्ये IEEE 802.1Q अंतर्गत VLAN विभाजन, 802.1X आणि RADIUS द्वारे डायनॅमिक VLAN असाइनमेंट, हाय-डेन्सिटी वातावरणासाठी RF नियोजन, आणि GDPR आणि PCI-DSS अंतर्गत अनुपालन बाबींचा समावेश आहे. स्थळ संचालक आणि इमारत व्यवस्थापकांना प्रत्यक्ष उपयोजनापूर्वी उपयुक्त आर्किटेक्चर मार्गदर्शन, वास्तविक-जगातील केस स्टडीज आणि टाळण्यासारख्या कॉन्फिगरेशन त्रुटी मिळतील.
Mean time to innocence: WiFi चे दोषारोपण कसे टाळायचे
Mean time to innocence (MTTI) हा एक महत्त्वाचा मेट्रिक आहे जो नेटवर्कची समस्या ही त्यांची चूक नाही हे सिद्ध करण्यासाठी आयटी टीम्स किती वेळ घालवतात हे ठरवतो. हा मार्गदर्शक मल्टी-टेनंट वातावरणात एकमेकांवर दोषारोप करणे टाळण्यासाठी आणि सरासरी रिझोल्यूशन वेळ (MTTR) कमी करण्यासाठी सामायिक पुराव्यांच्या मदतीने पाच-पाच पायऱ्यांची एक ऑब्झर्वेबिलिटी कार्यपद्धती तपशीलवार सांगतो.
सामायिक WiFi इन्फ्रास्ट्रक्चरसाठी कायदेशीर आणि अनुपालन आवश्यकता
हे अधिकृत तांत्रिक संदर्भ मार्गदर्शक सामायिक WiFi इन्फ्रास्ट्रक्चर उपयोजित आणि व्यवस्थापित करण्यासाठी महत्त्वाच्या कायदेशीर, नियामक आणि आर्किटेक्चरल आवश्यकतांचे वर्णन करते. हे IT व्यवस्थापक, नेटवर्क आर्किटेक्ट आणि वेन्यू ऑपरेटर्सना मजबूत डेटा संरक्षण, कठोर पेमेंट सुरक्षा अनुपालन आणि एंटरप्राइझ मानके वापरून उच्च-कार्यक्षमता भाडेकरू अलगाव सुनिश्चित करण्यासाठी कृती करण्यायोग्य फ्रेमवर्क प्रदान करते.
तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?
आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.