तुम्ही कदाचित सध्या यातील कोणत्यातरी समस्येचा सामना करत असाल. एक नवीन शाखा, हॉटेल, क्लिनिक किंवा रिटेल साइट वेगाने सुरू करणे आवश्यक आहे. एक करिअर विलंबित आहे. दुसरी लिंक लाइव्ह आहे पण अस्थिर आहे. तुमचे क्लाउड ॲप्स प्रत्येक साइटवरून सारखे काम करत नाहीत. गर्दीच्या वेळी व्हॉईस कॉलिंगची गुणवत्ता खालावते. एखादा युझर म्हणतो "WiFi ठीक आहे" तर Microsoft 365 मात्र संथ चालत असते, ज्यावरून तुम्हाला नेमकी कोणतीच माहिती मिळत नाही.
हा रोजचाच वास्तव अनुभव आहे ज्यामुळे SD-WAN पेक्षा sd wan management अधिक महत्त्वाचे ठरते.
स्वस्त इंटरनेट सर्किट्स जोडणे हे कठीण काम नाही. आपले पथक पूर्णवेळ पॅकेट चेसर्स न बनवता एका विखुरलेल्या नेटवर्कवर नियंत्रण ठेवणे हे खरे कठीण काम आहे. हेतू निश्चित करण्यासाठी एकच जागा, काय बिघडले आहे हे पाहण्यासाठी एकच जागा आणि प्रत्येक साइटवर समान मानके लागू करण्यासाठी एकच जागा असणे आवश्यक आहे. मल्टी - टेनंट ठिकाणी, ट्रॅफिकने कोणत्या मार्गाचा वापर केला एवढेच नव्हे, तर युझर कोण आहे हे देखील नेटवर्कला समजणे आवश्यक आहे.
MPLS च्या पलीकडे - इंटेलिजेंट SD WAN Management चा उदय
जुने WAN सहसा त्याच तीन प्रकारे अपयशी ठरतात.
पहिले, ते महाग असतात. दुसरे, ते ताठर असतात. तिसरे, ते करिअरच्या सीमा, हँड - ऑफ्स आणि मॅन्युअल बदल प्रक्रियेच्या मागे आपल्या ऑपरेशनल समस्या लपवतात.
जर तुम्ही अधिक MPLS असलेल्या नेटवर्क्सचे व्यवस्थापन केले असेल, तर तुम्हाला हा प्रकार माहीत असेल. एक नवीन शाखा सुरू होते आणि कोणीतरी विचारते की तुम्ही ती किती लवकर जोडू शकता. याचे प्रामाणिक उत्तर सर्किट मिळण्याच्या वेळेवर, बॉक्स स्टेजिंगवर, CLI सुसंगततेवर आणि मूळ डिझाईन अजूनही SaaS ट्रॅफिकसाठी योग्य आहे की नाही यावर अवलंबून असते. दरम्यान, युझर्ससाठी महत्त्वाचे असलेले बहुतांश ॲप्लिकेशन्स आता केवळ एका डेटा सेंटरमध्ये राहत नाहीत.
जुने मॉडेल त्रासदायक का ठरले
पारंपारिक WAN डिझाईनमध्ये सेंट्रलायझेशन गृहीत धरले गेले होते. ट्रॅफिक परत कोर साइट्सकडे जात असे कारण तिथेच ॲप्लिकेशन्स आणि सुरक्षा व्यवस्था असायची.
पण आता बहुतेक संस्था अशा प्रकारे काम करत नाहीत. टीम्स क्लाउड सेवा, व्हॉईस आणि व्हिडिओ, ब्राउझर - आधारित टूल्स आणि ओळख प्लॅटफॉर्म वापरतात ज्यांना अनावश्यक बॅकहॉलची गरज नसते. नेटवर्कला अगदी शेवटच्या स्तरावर (edge) अधिक हुशारीने निर्णय घ्यावे लागतात.
उद्योग विश्लेषणात नमूद केलेल्या गार्टनरच्या अंदाजानुसार, २०१२ च्या अखेरीस, UK मधील मोठ्या प्रमाणावर झालेल्या स्वीकारार्हतेसह जागतिक स्तरावर ३०% उपक्रमांनी शाखांमध्ये SD-WAN तैनात केले होते, जे यापूर्वी १% पेक्षा कमी होते. याच विश्लेषणात असे नमूद केले आहे की UK मधील उपक्रमांनी सरासरी MPLS खर्च दरमहा £५०० प्रति Mbps पेक्षा जास्त नोंदवला होता, ज्यामुळे संस्थांना इंटरनेट लिंक्स वापरण्यास प्रवृत्त केले जे SD-WAN अधिक प्रभावीपणे व्यवस्थापित करू शकत होते ( SD-WAN च्या इतिहासावर कॅटो नेटवर्क्स ).
तो बदल महत्त्वाचा आहे कारण तो सांगतो की SD-WAN केवळ एक फॅशन म्हणून स्वीकारला गेला नाही. याने ऑपरेशनल विसंगती दूर केली.
sd wan management काय बदलते
SD-WAN management चे मूल्य हे केवळ “आम्ही MPLS ला ब्रॉडबँडने बदलले” हे नाही. हा खूपच मर्यादित दृष्टिकोन आहे.
महत्त्वाच्या बदलांमध्ये हे समाविष्ट आहे:
- तुम्ही व्यावसायिक उद्दिष्टे मध्यवर्ती पद्धतीने परिभाषित करता. व्हॉइस, पेमेंट ट्रॅफिक, गेस्ट ॲक्सेस, क्लाउड ॲप्स आणि बॅक-ऑफिस सिस्टम या सर्वांना एकाच प्रकारच्या ट्रीटमेंटची गरज नसते.
- तुम्ही पॉलिसी एकाच वेळी सर्व ठिकाणी लागू करता. यामुळे शाखांचे नेटवर्क व्यवस्थापन विस्कळीत आणि अनियंत्रित राहत नाही.
- तुम्हाला केवळ लिंकची स्थितीच नाही, तर सेवेची गुणवत्ता देखील दिसते. युझरचा अनुभव खराब असतानाही एखादा इंटरफेस सुरू असू शकतो.
- तुम्ही स्थानिक परावलंबित्व कमी करता. नवीन साइट्ससाठी नेहमीच प्रत्यक्ष उपस्थित राहून तज्ज्ञांच्या कॉन्फिगरेशनची आवश्यकता नसते.
व्यावहारिक नियम: जर तुमचे WAN अजूनही प्रत्येक साइटनुसार बदलणारे अपवाद आणि दीर्घ बदलांच्या कालावधीवर अवलंबून असेल, तर तुमची अडचण बँडविड्थची नाही. तुमची अडचण नियंत्रणाची आहे.
संस्था जेव्हा शाखेच्या कनेक्टिव्हिटीचे आधुनिकीकरण करतात तेव्हा त्यांना मिळणारे कार्यात्मक फायदे समजून घेणे ही एक चांगली सुरुवात आहे, जसे की मध्यवर्ती पॉलिसी नियंत्रण आणि उत्तम क्लाउड परफॉर्मन्स, जे या SD-WAN benefits च्या आढाव्यात समाविष्ट केले आहेत.
मुख्य संकल्पना सोपी आहे. SD-WAN हे WAN ला वैयक्तिकरित्या व्यवस्थापित केलेल्या सर्किट्समधून एका मध्यवर्ती व्यवस्थापित सेवा संरचनेत (service fabric) रूपांतरित करते. एकदा हे समजले की, उर्वरित मॉडेल समजणे सोपे होते.
SD WAN Management नियंत्रणाचे तीन मुख्य स्तंभ
SD-WAN management चा विचार एखाद्या एअर ट्रॅफिक कंट्रोल सिस्टम सारखा करा.
विमाने अजूनही त्यांच्या मार्गावर उडतात. नेटवर्कच्या भाषेत, ते तुमचे ब्रँच डिव्हाइसेस आणि ट्रान्सपोर्ट लिंक्स आहेत. परंतु सुरक्षित, कार्यक्षम हालचाली मध्यवर्ती नियोजन, सक्रिय नियंत्रण आणि स्पष्ट नियमावलीवर अवलंबून असतात. या तीन भागांशिवाय, तुम्हाला विलंब, संघर्ष आणि सतत मॅन्युअल हस्तक्षेपाचा सामना करावा लागतो.
सेंट्रलाइज्ड ऑर्केस्ट्रेशन (Centralised orchestration)
ऑर्केस्ट्रेटर हा फ्लाइट प्लॅनर सारखा आहे.
ही अशी सिस्टम आहे जिथे तुमची टीम टेम्पलेट्स, साइट प्रोफाईल, सेगमेंटेशन, बिझनेस हेतू आणि रोलआउट लॉजिक परिभाषित करते. तुम्ही Meraki, Aruba, VMware किंवा तत्सम प्लॅटफॉर्म चालवत असल्यास, हा तो भाग आहे जो तुम्हाला पुनरावृत्ती करण्याची क्षमता देतो. किरकोळ विक्री शाखा, हॉटेल किंवा प्रादेशिक कार्यालय कसे असावे हे तुम्ही ठरवता, नंतर तेच मॉडेल अनेक ठिकाणांवर लागू करता.
म्हणूनच झिरो-टच प्रोव्हिजनिंग (zero-touch provisioning) कार्य करते. ब्रँच एज डिव्हाइस येते, इंटरनेटशी कनेक्ट होते, योग्य कॉन्फिगरेशन डाउनलोड करते आणि प्रत्येक लोकेशनसाठी इंजिनियरने कमांड्स टाईप न करताच विस्तृत नेटवर्कचा भाग बनते.
IT व्यवस्थापकांसाठी, हे महत्त्वाचे आहे कारण सुसंगतता हे केवळ सोयीचे साधन नसून एक सुरक्षा आणि सपोर्टचे वैशिष्ट्य आहे. साइट्स दरम्यान मॅन्युअल फरक जितके कमी असतील, तितकाच तुमच्या टीमचा वेळ एका विशिष्ट ठिकाणाचे वर्तन वेगळे का आहे हे आठवण्याचा प्रयत्न करण्यात कमी खर्च होईल.
स्वयंचलित पॉलिसी अंमलबजावणी
controller हा मुख्य टॉवर आहे.
तो केवळ एक स्थिर योजना धरून ठेवत नाही. तो बदलत्या परिस्थितीला प्रतिसाद देतो आणि कडांना (edges) काय करावे ते सांगतो. येथे SD-WAN केवळ केंद्रीकृत न राहता ऑपरेशनल दृष्ट्या उपयुक्त ठरतो.
प्रगत controllers मध्ये, Dynamic Multipath Optimization (DMPO) हे लेटन्सी, जिटर आणि पॅकेट लॉसचे निरीक्षण करून सब-सेकंद पाथ सिलेक्शन कार्य करते. उच्च-गुणवत्तेच्या इंटेंट SLA अंतर्गत, ते ४०% लेटन्सी कमी करू शकते, आणि पॉलिसी अपडेट्स कडांवरील साधनांपर्यंत (edge devices) आठवड्यांऐवजी सेकंदात पोहोचू शकतात ( SD-WAN ट्रॅफिक मॅनेजमेंट आणि ॲप्लिकेशन कंट्रोलवर Forcepoint ).
त्या वाक्यात खूप काही सामावले आहे, म्हणून त्याचे सविस्तर विश्लेषण करूया.
जर MPLS गर्दीचे असेल पण ब्रॉडबँड सुरळीत असेल, तर controller ॲप्लिकेशन प्रवाह बदलू शकतो. जर व्हॉईस सेशनमध्ये जिटर दिसू लागला, तर controller त्याला वेगळ्या मार्गाने वळवू शकतो. पॉलिसी बदलल्यास, ब्रँचला स्थानिक तंत्रज्ञांची वाट पाहावी लागत नाही.
हाच फरक "नेटवर्क कॉन्फिगर केले आहे" आणि "नेटवर्क सक्रियपणे व्यवस्थापित केले जात आहे" यातील आहे.
एक स्थिर WAN सूचनांचे पालन करतो. तर व्यवस्थापित SD-WAN त्या सूचनांमुळे तुम्हाला अपेक्षित परिणाम मिळत आहेत की नाही हे सतत तपासत राहतो.
नियमपुस्तिका म्हणून पॉलिसी
पॉलिसी या संज्ञेवर अनेक वाचक अडखळतात कारण हा शब्द अमूर्त वाटतो.
पॉलिसी हा केवळ एक नियम आहे जो हेतू (intent) आणि कृती (action) यांना जोडतो.
उदाहरणार्थ:
- ॲप्लिकेशन हेतू: VoIP आणि पेमेंट सिस्टम्स सर्वात सुरळीत मार्गावर ठेवा.
- सुरक्षा हेतू: गेस्ट ट्रॅफिक ऑपरेशनल सिस्टम्सपासून वेगळे ठेवा.
- व्यवसाय हेतू: तात्पुरती साइट जलदपणे ऑनलाइन आणा, परंतु तिचा ॲक्सेस कडकपणे मर्यादित ठेवा.
- ऑपरेशनल हेतू: एखादी लिंक खराब झाल्यास, एखाद्या व्यक्तीच्या लक्षात येण्याची वाट न पाहता स्वयंचलितपणे फेलओव्हर करा.
काही पॉलिसी व्यापक असतात. काही अत्यंत विशिष्ट असतात. एक चांगली रचना सहसा या दोन्हीचा मेळ घालते.
हे स्तंभ एकत्र कसे काम करतात
येथे व्यावहारिक विभागणी दिली आहे:
| घटक | काम | तुमच्या टीमला काय दिसते |
|---|---|---|
| Orchestrator | टेम्पलेट्स आणि रोलआउट लॉजिक परिभाषित करतो | साइट मानके तयार करण्यासाठी एकच जागा |
| Controller | रिअल-टाइम स्टिअरिंग निर्णय घेतो | बदलत्या लिंक गुणवत्तेशी जलद जुळवून घेणे |
| पॉलिसी | व्यवसाय हेतूचे अंमलबजावणीयोग्य नियमांमध्ये भाषांतर करतात | सर्व साइट्सवर अंदाज लावता येण्याजोगे वर्तन |
गोंधळ साधारणपणे या सर्व गोष्टींना एकच मानण्यामुळे होतो. पण त्या तशा नाहीत.
ऑर्केस्ट्रेटोर तुम्हाला सुसंगतता देतो. कंट्रोलर तुम्हाला प्रतिसादक्षमता देतो. तर पॉलिसीज तुम्हाला गव्हर्नन्स देतात.
जर यापैकी एक जरी कमकुवत असेल, तर sd wan व्यवस्थापन निराशाजनक वाटते. तुमचे ट्रान्सपोर्टवरील पैसे वाचू शकतात, परंतु तुम्हाला ते ऑपरेशनल नियंत्रण मिळणार नाही ज्यामुळे हे मॉडेल स्वीकारणे फायदेशीर ठरते.
रिएक्टिव्ह अलार्म्स कडून प्रेडिक्टिव्ह इनसाइट्स कडे
अनेक WAN मॉनिटरिंग अजूनही बर्गलर अलार्मसारखेच कार्य करते. युजर्स त्रस्त झाल्यानंतर ते तुम्हाला काहीतरी चूक झाल्याचे सांगते.
आधुनिक SD-WAN व्यवस्थापनाने चांगल्या प्रकारे सुसज्ज असलेल्या सिस्टीममधून सतत येणाऱ्या टेलिमेट्रीप्रमाणे काम केले पाहिजे. सर्किट सुरू आहे की नाही हे तुम्ही विचारत नाही. तुम्ही हे विचारता की प्रत्यक्ष ॲप्लिकेशन्सना आवश्यक असणारा अनुभव मिळत आहे की नाही.
डॅशबोर्डने तुम्हाला काय सांगितले पाहिजे
एक उपयुक्त कन्सोलने किमान चार प्रकारची माहिती दर्शवली पाहिजे:
- लिंकचे आरोग्य: लेटन्सी (latency), जिटर (jitter), पॅकेट लॉस (packet loss), युटिलायझेशन (utilisation)
- ॲप्लिकेशन वर्तन: कोणते ॲप कार्यरत आहे, त्याने कोणता मार्ग घेतला आणि पॉलिसीने त्यावर योग्य प्रक्रिया केली की नाही
- साईट संदर्भ: समस्या केवळ एकाच ब्रँचपुरती मर्यादित आहे की संपूर्ण इस्टेट-व्यापी आहे
- युझरवरील प्रभाव: व्हॉईस, व्हिडिओ, SaaS किंवा ट्रान्झॅक्शनल फ्लो खालावला आहे का
अनेक टीम्सना या टप्प्यावर जाणीव होते की ते बऱ्याच अंशी अंधारात काम करत होते. जेव्हा केवळ गर्दीच्या वेळेत व्हॉईस क्वालिटी खराब असते किंवा जेव्हा एखादा ISP एका ॲप्लिकेशनसाठी खराब आणि दुसऱ्यासाठी चांगला काम करतो, तेव्हा "लिंक सुरू आहे" याने मदत होत नाही.
महत्त्वाचे SD-WAN मॅनेजमेंट KPIs
| KPI वर्गवारी | मेट्रिक | चांगले लक्ष्य | हे का महत्त्वाचे आहे |
|---|---|---|---|
| पाथ क्वालिटी | लेटन्सी (Latency) | कमी असणे अधिक चांगले, आणि ॲप्लिकेशनच्या गरजांनुसार जुळलेले असावे | जास्त लेटन्सीमुळे व्हॉईस, व्हिडिओ आणि SaaS संथ वाटतात |
| पाथ क्वालिटी | जिटर (Jitter) | रिअल - टाईम ट्रॅफिकसाठी कमी असणे अधिक चांगले | जिटरमुळे व्हॉईस आणि व्हिडिओ परफॉर्मन्स अस्थिर होतो |
| पाथ क्वालिटी | पॅकेट लॉस (Packet loss) | शक्य तितके शून्याच्या जवळ | पॅकेट लॉसमुळे कॉल क्वालिटी आणि ॲप्लिकेशन प्रतिसादक्षमतेवर परिणाम होतो |
| कॅपॅसिटी | लिंक युटिलायझेशन | सतत जास्त राहणाऱ्या युटिलायझेशनवर लक्ष ठेवा | युजर्सनी तक्रार करण्यापूर्वीच बऱ्याचदा कंजेशन (गर्दी) दिसून येते |
| ॲप्लिकेशन अनुभव | ॲप्लिकेशननुसार थ्रूपुट | ॲप आणि साईट प्रोफाईलसाठी योग्य असलेले थ्रूपुट | बिझनेस ट्रॅफिकला आवश्यक असलेली बँडविड्थ मिळत आहे की नाही हे दर्शवते |
| ऑपरेशन्स | पॉलिसी मॅच अचूकता | सर्व साईट्सवर उच्च सुसंगतता | ट्रॅफिकचे वर्गीकरण आणि योग्य मार्गक्रमण होत असल्याची खात्री करते |
| अवेलेबिलिटी | फेलओव्हर वर्तन | जलद रिकव्हरी | आउटेज युजर्सना जाणवू लागले आहेत की नाही हे तुम्हाला सांगते |
अचूक मर्यादा परिस्थितीनुसार बदलते. अतिथी WiFi चा मोठा वापर असणारे ठिकाण, एखादे क्लिनिक, आणि संपर्क केंद्र (contact centre) या सर्वांच्या मर्यादा सारख्या नसतील.
जिथे AI आणि ML महत्त्वाची भूमिका बजावतात
AI/ML-वर्धित SD-WAN ॲनालिटिक्स रिअल-टाइम टेलिमेट्रीसह ऐतिहासिक बेसलाइन्स एकत्र करून ९५% अचूकतेसह बिघाड आधीच ओळखू शकतात. UK मधील रिटेल क्षेत्रामध्ये, यामुळे सिंगल लिंक्सवरील पीक-अवर गर्दी दरम्यान २०-३०% VoIP पॅकेट लॉस कमी करण्यास मदत होते, डाउनटाइम ६०% ने कमी होतो, आणि एकूण कामगिरीमध्ये ५८.२०% ची वाढ दिसून आली आहे ( Broadcom AppNeta best practices for operating and monitoring an SD-WAN network ).
हे उपयुक्त ठरते कारण सिस्टीम केवळ धोक्याचा लाल दिवा दाखवत नाही, तर या प्रकारच्या ब्रँचमध्ये "शुक्रवारी दुपारची सामान्य स्थिती" कशी असते हे शिकते, आणि वापरकर्त्यांनी सेवा केंद्राकडे तक्रार करण्याआधीच विचलनांवर (deviations) प्रकाश टाकते.
एक सक्षम ऑपरेशन्स टीम याचा तीन प्रकारे वापर करते:
- बेसलाइनिंग: प्रत्येक साइट आणि ॲपसाठी सामान्य स्थिती कशी असावी हे समजून घेणे.
- भाकीत (Prediction): पूर्णपणे सेवा खंडित होण्यापूर्वी वाढत्या जोखमीचा शोध घेणे.
- ट्यूनिंग: पुराव्यांच्या आधारे पाथ प्राधान्ये, मर्यादा आणि क्षमता योजनांमध्ये बदल करणे.
ऑपरेशनल टीप: जर सर्व अलर्ट्स तितकेच महत्त्वाचे वाटत असतील, तर तुमचे मॉनिटरिंग पुरेसे प्रगत नाही. चांगल्या SD-WAN ॲनालिटिक्सने तुमच्या टीमला विनाकारण येणाऱ्या अलर्ट्स आणि वापरकर्त्यांवर परिणाम करणाऱ्या जोखमींमधील फरक ओळखण्यास मदत केली पाहिजे.
ट्रबलशूटिंगमधील सुधारणा
ॲनालिटिक्सशिवाय, तिकिटावर केवळ "ब्रँचमध्ये कॉल्स खराब येत आहेत" असा उल्लेख असतो.
प्रगत SD-WAN व्हिजिबिलिटीसह, संभाषण बदलते. तुम्ही पाहू शकता की एखाद्या ब्रॉडबँड सर्किटवर पॅकेट लॉस वाढला आहे का, व्हॉइस चुकीच्या पाथला जोडलेला राहिला आहे का, फेलओव्हर ट्रिगर झाले आहे का, आणि या समस्येचा परिणाम सर्व रिअल-टाइम ॲप्सवर झाला आहे की केवळ एकावर झाला आहे.
यामुळे समस्या दुरुस्त करण्यासाठी लागणारा सरासरी वेळ (mean time to repair) कमी होतोच, पण चूक नेमकी कोणाची आहे हे शोधण्याचा वेळ (mean time to innocence) देखील कमी होतो. कधीकधी समस्या नेटवर्कमध्ये असते, कधीकधी ती ISP ची असते, तर कधीकधी ती अपस्ट्रीम ॲप्लिकेशनच्या कामगिरीची असते. चांगली टेलिमेट्री नेमके काय घडले आहे हे सिद्ध करण्यास मदत करते.
फक्त एक वेगवान पाईप नाही, तर सुरक्षित फॅब्रिक तयार करणे
एक सामान्य चूक म्हणजे SD-WAN कडे केवळ ट्रान्सपोर्ट प्रोजेक्ट म्हणून पाहणे. एड्जेस खरेदी करा, सर्किट्स सुरू करा, ट्रॅफिकचे नियमन करा आणि पैशांची बचत करा.
या दृष्टिकोनामध्ये उणीव राहते. जर तुमचे मॅनेजमेंट प्लेन ट्रॅफिक अनुकूल करू शकत असेल परंतु एकसंध सुरक्षा धोरण लागू करू शकत नसेल, तर तुम्ही जोखीम वेगाने पसरवण्यासाठी फक्त एक जलद मार्ग तयार केला आहे.
सुरक्षा त्याच ऑपरेटिंग मॉडेलमध्ये असणे आवश्यक आहे
आधुनिक WAN ऑपरेशन्सना अशा सुरक्षा नियंत्रणांची गरज असते जी कनेक्टिव्हिटीमधील बदलांच्या बरोबरीने तितक्याच वेगाने काम करू शकतील.
याचा साधारणपणे असा अर्थ होतो की next-generation firewalling, intrusion prevention, secure web filtering, विभागणी आणि पॉलिसी-आधारित ऍक्सेस यासारखी कार्ये एकाच मॅनेजमेंट वर्कफ्लोमध्ये एकत्र आणणे. हे नियंत्रणे थेट एजवर असोत, क्लाउड-वितरित असोत किंवा दोन्ही एकत्र असोत, महत्त्वाचा मुद्दा म्हणजे ऑपरेशनल ऐक्य.
जर तुमची नेटवर्क टीम एका कन्सोलमध्ये पाथ पॉलिसी अपडेट करत असेल तर तुमची सिक्युरिटी टीम दुसऱ्या ठिकाणी इंटरनेट ऍक्सेस नियंत्रणे अपडेट करत असेल, तर तफावत निर्माण होण्याची खात्री असते. शाखांमध्ये विसंगत नियम लागू होतात, अपवाद वाढतात आणि ट्रबलशूटिंगमध्ये अडथळे येतात.
व्यवहारात SASE का महत्त्वाचे आहे
येथे SASE विचार उपयुक्त ठरतो. हे संक्षेप लोकप्रिय आहे म्हणून नाही, तर ते एका व्यावहारिक वास्तवाचे प्रतिनिधित्व करते म्हणून. युजर्स, डिव्हाइसेस, शाखा आणि क्लाउड सेवा या सर्वांना सुसंगत वागणुकीची गरज असते.
लोकल ब्रेकआउट कनेक्शनवरील शाखेतील युजरला एक सिक्युरिटी पोश्चर आणि रिमोट युजरला चुकून दुसरे सिक्युरिटी पोश्चर मिळता कामा नये. मॅनेजमेंट मॉडेलने पॉलिसी पोर्टेबल बनवली पाहिजे.
याचा अर्थ असा आहे की:
- सुसंगत तपासणी: सेंट्रल डेटा सेंटरमधून ट्रॅफिक जात नसतानाही इंटरनेट-बाउंड ट्रॅफिक नियंत्रित केले पाहिजे.
- विभाजित ट्रस्ट झोन्स: अतिथी, कर्मचारी, IoT, पेमेंट सिस्टीम आणि ऑपरेशनल तंत्रज्ञान एकाच फ्लॅट डोमेनमध्ये नसावेत.
- सामायिक पॉलिसी लॉजिक: राउटिंग आणि सुरक्षेच्या निर्णयांनी एकमेकांना विरोध करण्याऐवजी एकमेकांना पूरक ठरले पाहिजे.
दुर्लक्षित केलेला ऑपरेटर वर्कफ्लो
दैनंदिन स्तरावर, सुरक्षित ऑपरेशन्स अजूनही टूल्स आणि सवयींवर अवलंबून असतात. सेंट्रलाइज्ड प्लॅटफॉर्म्स असूनही, इंजिनिअर्सना अनेकदा एज व्हॅलिडेशन, चेंज कंट्रोल आणि ऑडिट-फ्रेंडली ऍडमिनिस्ट्रेशनसाठी शिस्तबद्ध ऍक्सेस पद्धतींची आवश्यकता असते. जर तुमची टीम एंडपॉइंट वर्कफ्लो सुधारत असेल, तर secure network management with tools like Mac SSH clients याबद्दलचे हे मार्गदर्शक एक उपयुक्त ऑपरेशनल संदर्भ आहे.
हे महत्त्वाचे आहे कारण आर्किटेक्चर डायग्राम्स अनेकदा चेंज विंडोज आणि मानवी ऍक्सेस पाथ्सच्या व्यावहारिक बाबींकडे दुर्लक्ष करतात. चांगली SD-WAN मॅनेजमेंट मॅन्युअल प्रयत्न कमी करते, परंतु ते योग्य ऍडमिनिस्ट्रेशन पद्धतींची आवश्यकता पूर्णपणे काढून टाकत नाही.
सुरक्षा हे असे वैशिष्ट्य नाही जे तुम्ही रोलआउटनंतर SD-WAN वर जोडता. हा पहिल्या दिवसापासून नियंत्रण मॉडेलचा एक भाग असतो.
ऍक्सेस कंट्रोल हा संरचनेचाच एक भाग आहे
अनेक टीम्स साइट विभागणी आणि फायरवॉल नियमांसह प्रारंभ करतात, नंतर त्यांच्या लक्षात येते की प्रत्येक वातावरणात कोणते युजर्स आणि डिव्हाइसेस प्रवेश करू शकतात यावर अधिक मजबूत नियंत्रणाची आवश्यकता आहे.
तिथेच network access control solutions चे व्यापक दृष्टिकोन संबंधित ठरतात. WAN हे ट्रॅफिक कुठे जाईल हे ठरवू शकते, परंतु ऍक्सेस कंट्रोल हे ठरवते की त्या ट्रॅफिकवर प्रथम स्थानावर विश्वास ठेवला पाहिजे की नाही.
तुम्ही या विभागातून एक गोष्ट लक्षात ठेवणार असाल, तर ती ही असू द्या. आधुनिक WAN हे केवळ मार्ग निवडणारे इंजिन नाही. ते एक secure fabric आहे ज्याने व्यावसायिक रहदारी वाहून नेली पाहिजे, जोखीम वेगळी केली पाहिजे आणि शाखा, क्लाउड आणि रिमोट ॲक्सेसवर पॉलिसी सुसंगत ठेवली पाहिजे.
Identity Based Access द्वारे नेटवर्कला युझरशी जोडणे
हा तो फरक आहे जो इतर अनेक चांगल्या SD-WAN उपयोजनांना प्रभावित करतो.
नेटवर्कला ॲप्लिकेशन्स, मार्ग आणि साइट्सबद्दल खूप माहिती असते. परंतु ॲक्सेसची विनंती करणाऱ्या प्रत्यक्ष व्यक्ती किंवा डिव्हाइसबद्दल त्याला बरीच कमी माहिती असते. सामान्य ऑफिसमध्ये ही आधीच एक मर्यादा असते. हॉटेल, रिटेल आउटलेट, विद्यार्थ्यांचे निवासस्थान, मिश्र-वापर मालमत्ता किंवा आरोग्य सेवा वातावरणात, हा एक गंभीर डिझाइन दोष बनतो.
केवळ पाथ पॉलिसी पुरेशी का नाही
पारंपारिक SD-WAN पॉलिसी असे सांगू शकते:
- Teams ला प्राधान्य द्या
- गेस्ट इंटरनेटसाठी ब्रॉडबँडला प्राधान्य द्या
- पेमेंट रहदारी सर्वात विश्वसनीय लिंकवर ठेवा
- IoT डिव्हाइसेस वेगळे करा
हे चांगले नियम आहेत. पण ते पुरेसे नाहीत.
ते यांसारख्या प्रश्नांची उत्तरे देत नाहीत:
- हा कर्मचारी आहे, गेस्ट आहे, कंत्राटदार आहे की रहिवासी आहे?
- डिव्हाइस मॅनेज्ड आहे, अज्ञात आहे की जुने आहे?
- या युझरला अंतर्गत ॲप्लिकेशन ॲक्सेस, केवळ-इंटरनेट ॲक्सेस किंवा विभागलेला सेवा ॲक्सेस मिळायला हवा का?
- डिरेक्टरी स्टेटस बदलल्यावर ॲक्सेस त्वरित रद्द केला जाऊ शकतो का?
ओळख-माहिती नसलेल्या ॲक्सेसशिवाय, टीम्स अनेकदा सामायिक केलेले पासवर्ड, Captive Portal उपाय, स्थानिक अपवाद किंवा स्थिर डिव्हाइस क्रेडेंशियलसह हा फरक तात्पुरता भरून काढतात. यामुळे घर्षण निर्माण होते आणि zero-trust ध्येये कमकुवत होतात.
मल्टी-टेनंट वास्तव
एक २०२५ चा UK ISP सर्व्हे दर्शवतो की ४२% एंटरप्रायझेस आयडेंटिटी मॅनेजमेंट हे मुख्य SD-WAN आव्हान असल्याचे सांगतात. याच साहित्यात असे नमूद केले आहे की २०२४ ते २०२५ दरम्यान सार्वजनिक WiFi हॉटस्पॉट्समध्ये २८% वाढ झाली आहे, ज्यापैकी ६५% हॉटस्पॉट्स हॉस्पिटॅलिटी आणि रिटेलमध्ये आहेत, जिथे नेटवर्क आणि युझर ओळख यांच्यातील विलग मॅनेजमेंट सुरक्षा जोखीम निर्माण करते आणि एन्क्रिप्टेड फर्स्ट-पॅकेट ॲक्सेससाठीच्या वाढत्या UK NIS2 अपेक्षा पूर्ण करण्यात अपयशी ठरते ( Cisco SD-WAN ebook PDF ).
ही एका परिच्छेदातील कार्यात्मक समस्या आहे. शाखा नेटवर्क कदाचित मध्यवर्तीरित्या व्यवस्थापित केले जाऊ शकते, परंतु युझर ॲक्सेस बऱ्याचदा इतर ठिकाणी, वेगवेगळ्या साधनांसह, वेगवेगळ्या पॉलिसी लॉजिकसह आणि वेगवेगळ्या टीम्सद्वारे हाताळला जातो.
मल्टी-टेनंट ठिकाणी, या विभाजनामुळे वास्तविक समस्या उद्भवतात:
| दृश्य (Scenario) | केवळ-नेटवर्क दृष्टिकोन | ओळख-माहिती असलेला (Identity-aware) दृष्टिकोन |
|---|---|---|
| पाहुणे (Guest) वेन्यूच्या WiFi शी कनेक्ट होतात | सामान्य इंटरनेट ट्रॅफिक दिसते | हे समजते की हा मर्यादित विशेषाधिकार असलेला पाहुणे युझर आहे |
| कर्मचारी सदस्य लॉग इन करतात | व्यवसाय ॲपचे ट्रॅफिक दिसते | डिरेक्टरी आयडेंटिटीशी जोडलेला कर्मचारी ॲक्सेस लागू होतो |
| कंत्राटदार अनमॅनेज्ड डिव्हाइससह येतो | दुसरा एंडपॉइंट दिसतो | भूमिका आणि डिव्हाइस विश्वासावर आधारित ॲक्सेस प्रतिबंधित होतो |
| लेगसी डिव्हाइस कनेक्ट होते | केवळ MAC किंवा सेगमेंट दिसतो | डिव्हाइसला कडक नियंत्रण असलेल्या पॉलिसी लेनमध्ये ठेवले जाते |
युनिफाइड मॉडेल कसे दिसते
सर्वात चांगला परिणाम म्हणजे एक एकत्रित नियंत्रण मॉडेल (joined-up control model).
SD-WAN लेयर पाथ क्वालिटी, सेगमेंटेशन, ब्रँच कनेक्टिव्हिटी आणि पॉलिसीचे वितरण व्यवस्थापित करते. आयडेंटिटी लेयर ऑथेंटिकेशन, भूमिका, डिव्हाइस संदर्भ आणि सततचे ॲक्सेस निर्णय व्यवस्थापित करते. दोन्ही मिळून प्रत्यक्ष झिरो ट्रस्टच्या जवळ जाणारी सिस्टीम तयार करतात.
यामुळे पॉलिसी सामान्य ऐवजी अधिक अचूक बनते.
"कोलाबोरेशन ट्रॅफिकला प्राधान्य द्या" या ऐवजी, पॉलिसी आता "विश्वासू डिव्हाइसेसवरील अधिकृत कर्मचाऱ्यांसाठी कोलाबोरेशन ट्रॅफिकला परवानगी आणि प्राधान्य द्या, तर पाहुण्यांना तो ॲक्सेस नाकारा आणि लेगसी एंडपॉइंट्स वेगळे करा" अशी बनते. ही अत्यंत योग्य सूचना आहे.
डिझाइन तत्त्व: नेटवर्क पॉलिसी ट्रॅफिकला कुठे जायचे आहे हे सांगते. आयडेंटिटी पॉलिसी नेटवर्कला सांगते की तिथे जाण्याची परवानगी कोणाला दिली पाहिजे.
फर्स्ट-पॅकेट ट्रस्ट का महत्त्वाचा आहे
Captive Portals आणि शेअर्ड क्रेडेंशियल्स हे जुन्या ॲक्सेस मॉडेलचे भाग आहेत. ते युझर्ससाठी कठीण आणि ऑपरेटरसाठी कमकुवत आहेत.
डिरेक्टरी इंटिग्रेशन, सर्टिफिकेट-ग्रेड ट्रस्ट आणि Passpoint तसेच OpenRoaming सारख्या मानकांवर आधारित आयडेंटिटी-आधारित ॲक्सेस निर्णय आधीच घेतो. एका क्लिष्ट हँडऑफऐवजी, सेशन मजबूत खात्रीने सुरू होते.
जर तुम्ही ब्रँच कनेक्टिव्हिटीला अधिक व्यापक अशा zero trust network access तत्त्वांशी सुसंगत करत असाल तर हे विशेषतः महत्त्वाचे ठरते. झिरो ट्रस्ट ही केवळ रिमोट-ॲक्सेसपुरती मर्यादित संकल्पना राहत नाही, तर ती तुम्ही प्रत्यक्ष वेन्यूमध्येही लागू करू शकता.
याचा व्यावहारिक धडा सोपा आहे. SD-WAN तुम्हाला नेटवर्कवर नियंत्रण देते. आयडेंटिटी-आधारित ॲक्सेस तुम्हाला ते कोण आणि कोणत्या अटींवर वापरू शकते यावर नियंत्रण देतो. शेअर्ड वातावरणात, तुम्हाला दोन्हीची आवश्यकता असते.
SD WAN ऑपरेशनल रनबुक्सच्या मदतीने सिद्धांत प्रत्यक्षात आणणे
चांगले आर्किटेक्चर केवळ तेव्हाच महत्त्वाचे ठरते जेव्हा तुमची टीम दबावाखाली देखील त्याचे वारंवार यशस्वी संचालन करू शकते.
तिथेच ऑपरेशनल रनबुक्स मदत करतात. ते SD-WAN मॅनेजमेंटला एका डिझाइन संकल्पनेतून विश्वसनीय कृतींच्या संचामध्ये बदलतात, ज्याचे कनिष्ठ इंजिनिअर्स पालन करू शकतात आणि वरिष्ठ इंजिनिअर्स त्यावर विश्वास ठेवू शकतात.
नवीन साईट ऑनलाइन आणण्यासाठी रनबुक
नवीन ब्रँच, कॅफे, क्लिनिक किंवा हॉटेलसाठी कोणत्याही कठीण डिप्लॉयमेंट प्रक्रियेची आवश्यकता नसते.
एक व्यावहारिक रोलआउट सहसा याप्रमाणे दिसतो:
साईट प्रोफाईल नियुक्त करा ठिकाणाचा नकाशा एका मानक डिझाइनशी सुसंगत करा. रिटेल आणि कॉर्पोरेट ऑफिस सारखे नसतात. हॉस्पिटॅलिटी आणि हेल्थकेअर सारखे नसतात. प्रोफाइलने आधीच वर्गीकरण, पसंतीचे ट्रान्सपोर्ट आणि मूलभूत सुरक्षा परिभाषित केली पाहिजे.
झिरो-टच प्रोव्हिजनिंगसाठी एज तयार करा डिव्हाइसची ऑर्केस्ट्रेटरमध्ये नोंदणी करा, त्याला योग्य टेम्पलेटशी जोडणी करा आणि त्याच्या अपेक्षित अपलिंक्स आणि पॉलिसी ग्रुपची पुष्टी करा.
ट्रान्सपोर्ट वर्तनाची पडताळणी करा एकदा ऑनलाइन झाल्यावर, सर्किट्स योग्यरित्या ओळखले गेले आहेत की नाही आणि कंट्रोलर प्रत्येक लिंकला समान वागणूक देण्याऐवजी पाथ गुणवत्तेचे मूल्यांकन करत आहे की नाही हे तपासा.
वर्गीकरण आणि ॲक्सेस सीमांची पुष्टी करा गेस्ट, कर्मचारी, ऑपरेशन्स आणि डिव्हाइस ट्रॅफिक त्वरित योग्य झोनमध्ये जावे.
ॲप्लिकेशन चाचण्या चालवा व्हॉइस, पेमेंट, लाइन-ऑफ-बिझनेस ॲक्सेस आणि सामान्य इंटरनेट ब्रेकआउट यासारख्या गंभीर अनुभवांच्या लहान संचाची पडताळणी करा.
एक प्रगल्भ टीम याकडे एक हस्तकला प्रकल्प म्हणून न पाहता एक चेकलिस्ट म्हणून पाहते.
पॉलिसी बदल सुरक्षितपणे लागू करण्यासाठी रनबुक
पॉलिसीतील बदल हेच केंद्रीय व्यवस्थापनाचे खरे मूल्य दाखवून देतात.
समजा तुम्हाला एका ॲप्लिकेशन श्रेणीसाठी इंटरनेट ॲक्सेस कडक करायचा आहे, किंवा विशिष्ट प्रकारच्या सर्व साइट्सवर व्हॉइससाठी पाथ पसंती बदलायची आहे. त्याची सोपी पद्धत खालीलप्रमाणे आहे:
- साइट-बाय-साइट अपवाद करण्याऐवजी केंद्रीय पॉलिसी सेट संपादित करा.
- बदलांची व्याप्ती योग्य डिव्हाइस ग्रुप किंवा साइट क्लासपुरती मर्यादित ठेवा.
- लागू करण्यापूर्वी पॉलिसी क्रम आणि विवादांचे पुनरावलोकन करा.
- बदल युझरला दिसणारा असल्यास नियंत्रित वेळेत लागू करा.
- अपेक्षित मॅचेसची पुष्टी करण्यासाठी आणि कोणतेही अनपेक्षित दुष्परिणाम नसल्याची खात्री करण्यासाठी लागू केल्यानंतर लाइव्ह टेलिमेट्रीचे निरीक्षण करा.
टीम्सना सहसा बदल लागू केल्याने त्रास होत नाही. तर ते खराब पॉलिसी स्वच्छतेमुळे होते. खूप ओव्हरलॅपिंग नियम, अस्पष्ट नावे आणि कधीही साफ न केलेले आपत्कालीन अपवाद यामुळे समस्या उद्भवतात.
पॉलिसीची नावे वाचनीय ठेवा. “Policy_27B_Final” पेक्षा “Retail-Guest-Internet-Default” हे नाव अधिक चांगले आहे.
खराब कॉल किंवा स्लो ॲपच्या ट्रबलशूटिंगसाठी रनबुक
जेव्हा एखादा युझर खराब व्हिडिओ मीटिंग किंवा तुटक कॉलची तक्रार करतो, तेव्हा थेट WiFi किंवा ISP ला दोष देणे सुरू करू नका.
खालील संक्षिप्त निर्णय प्रवाहाचा वापर करा:
| तपासणी | तुम्ही काय शोधत आहात | संभाव्य पुढील पाऊल |
|---|---|---|
| ॲप्लिकेशन पाथ | ॲपने इच्छित ट्रान्सपोर्टचा वापर केला का? | पॉलिसी मॅच किंवा पाथ पसंती दुरुस्त करा |
| लिंक आरोग्य | तक्रारीदरम्यान लेटन्सी, जिटर किंवा लॉस होता का? | ट्रॅफिक हलवा किंवा कॅरियर समस्येचे निवारण करा |
| साइट पॅटर्न | एक युझर, एक साइट, की अनेक साइट्स? | स्थानिक विरुद्ध सिस्टेमिक समस्या वेगळी करा |
| वेळ परस्परसंबंध | वापराच्या उच्च वेळेत (peak usage) घसरण झाली का? | क्षमता किंवा ट्रॅफिक शेपिंगचे पुनरावलोकन करा |
| सुरक्षा धोरण प्रभाव (Security policy impact) | ट्रॅफिक अनपेक्षितपणे तपासले गेले किंवा ब्लॉक केले गेले का? | नियम क्रम किंवा अपवाद हाताळणी (exception handling) समायोजित करा |
येथील केंद्रीय दृश्यमानता वेळ वाचवते. आपण आता तुकड्यांवरून अंदाज लावत नाही आहात. आपण एकाच ठिकाणाहून धोरण, मार्ग आणि वापरकर्ता प्रभाव ट्रॅक करत आहात.
ऑपरेशन्स स्वच्छ ठेवणारी सवय
सर्वोत्तम runbooks मध्ये एका अंतिम पायरीचा समावेश असतो जी टीम्स बहुधा वगळतात.
दुरुस्तीनंतर, मानक (standard) अपडेट करा. तुमचे मूळ प्रोफाइल खूप व्यापक असल्यामुळे एखाद्या साइटला एकदाच बदल करण्याची आवश्यकता असल्यास, एकतर त्याला मान्यताप्राप्त प्रकार म्हणून औपचारिक करा किंवा अपवाद काढून टाका. उत्पादनात दस्तऐवजीकरण नसलेला बदल तसाच सोडू नका.
ती शिस्त कोणत्याही डॅशबोर्ड वैशिष्ट्यापेक्षा अधिक महत्त्वाची आहे. कालांतराने, हेच एका व्यवस्थितपणे व्यवस्थापित केल्या जाणाऱ्या SD-WAN इस्टेटला आणि ज्या गोंधळाला बदलण्यासाठी ते आणले होते तोच गोंधळ हळूहळू पुन्हा निर्माण करणाऱ्या इस्टेटला एकमेकांपासून वेगळे करते.
नेटवर्किंगचे भविष्य - युनिफाइड आणि आयडेंटिटी अवेयर
जुन्या WAN मॉडेलने एक संकुचित प्रश्न विचारला होता. आपण साइट्स कशा कनेक्ट करू?
ते आता पुरेसे नाही. आधुनिक ऑपरेशन्सना एकाच वेळी प्रश्नांच्या मोठ्या संचाचे उत्तर देणे आवश्यक आहे. आपण साइट्स कशा कनेक्ट करू, मार्गांची निवड हुशारीने कशी करू, सुरक्षा सातत्याने कशी लागू करू, ॲप्लिकेशनचे आरोग्य कसे समजून घेऊ आणि केवळ स्थानाऐवजी ओळखीच्या (identity) आधारावर प्रवेशाचे निर्णय कसे घेऊ?
म्हणूनच खालील ट्रान्सपोर्ट मिक्सपेक्षा sd wan management अधिक महत्त्वाचे आहे.
प्रौढ (mature) टीम्स प्रत्यक्षात काय तयार करत आहेत
अंतिम ध्येय डॅशबोर्ड नाही. हे एक ऑपरेटिंग मॉडेल आहे.
सर्वात मजबूत वातावरणात खालील गोष्टी एकत्र येतात:
- केंद्रीय ऑर्केस्ट्रेशन (Central orchestration) जेणेकरून साइट्स सुसंगत राहतील
- रिअल-टाइम नियंत्रण जेणेकरून नेटवर्क बदलत्या परिस्थितीशी जुळवून घेईल
- टेलीमेट्री आणि विश्लेषण (Telemetry and analytics) जेणेकरून वापरकर्त्यांनी तक्रार करण्यापूर्वी टीम्स कारवाई करू शकतील
- एकात्मिक सुरक्षा (Integrated security) जेणेकरून स्थानिक ब्रेकआउट स्थानिक धोका बनणार नाही
- आयडेंटिटी-अवेयर प्रवेश (Identity-aware access) जेणेकरून वापरकर्ते आणि उपकरणांना पहिल्या कनेक्शनपासूनच योग्य पातळीचा विश्वास मिळेल
हे भाग एकमेकांना मजबूत करतात. जर एक जरी गहाळ असेल, तर संपूर्ण डिझाइन कमी प्रभावी वाटते.
ओळख (identity) ही मॅच्युरिटीची पुढची पायरी का आहे
केवळ सर्किट्स आणि ॲप्लिकेशन्स समजणारे नेटवर्क उपयुक्त आहे. परंतु वापरकर्ते, भूमिका, उपकरणे आणि प्रवेशाची स्थिती समजणारे नेटवर्क अधिक लवचिक असते.
अशा वातावरणात हे सर्वात महत्त्वाचे ठरते जिथे अनेक लोक समान भौतिक पायाभूत सुविधा सामायिक करतात परंतु त्यांनी समान विश्वास पातळी सामायिक करू नये. हॉस्पिटॅलिटी, रिटेल, निवासी, इव्हेंट्स, ट्रान्सपोर्ट आणि हेल्थकेअर या सर्वांना या समस्येचा त्वरित सामना करावा लागतो.
भविष्यातील WAN हे सॉफ्टवेअर-डिफाइंड आहे, परंतु ती अंतिम रेषा नाही. ते आयडेंटिटी-अवेयर देखील असणे आवश्यक आहे.
जेव्हा टीम्स हे अचूकपणे करतात, तेव्हा कामकाज अधिक सुरळीत होते. नवीन साईट्स सुरू करणे सोपे होते. पॉलिसीमधील बदल अधिक सुरक्षितपणे लागू करता येतात. ट्रबलशूटिंग जलद होते. सुरक्षा वर्कअराउंड्सवर कमी अवलंबून राहते. युजर्सना ब्रांच नेटवर्किंग, WiFi ऑनबोर्डिंग आणि ॲक्सेस कंट्रोलमधील फरक जाणवणे बंद होते.
हे एक महत्त्वपूर्ण आश्वासन देते. केवळ एक चांगला WAN नाही, तर तो व्यवस्थापित करणाऱ्या आणि त्यावर अवलंबून असलेल्या प्रत्येकासाठी अधिक सुसंगत वातावरण.
तुम्ही नेटवर्क-पातळीवरील नियंत्रण आणि युझर-पातळीवरील ॲक्सेस यांमधील अंतर कमी करण्याचा प्रयत्न करत असल्यास, Purple संस्थांना शेअर्ड पासवर्ड्स आणि क्लिष्ट कॅप्टिव्ह पोर्टल्सच्या जागी पाहुणे, कर्मचारी आणि मल्टी-टेनंट वातावरणासाठी ओळख-आधारित, पासवर्डशिवाय WiFi ॲक्सेस प्रदान करण्यात मदत करते. झिरो-ट्रस्ट विचार थेट नेटवर्कच्या कडेपर्यंत (edge) पोहोचवण्याचा हा एक व्यावहारिक मार्ग आहे, विशेषतः अशा ठिकाणी जिथे केवळ SD-WAN युझर ओळखीची समस्या सोडवू शकत नाही.
