Skip to main content
कुछ प्रदाता API एक्सेस को स्रोत IP addresses की स्वीकृत सूची तक सीमित रखते हैं। यह प्रतिबंध सक्षम होने पर आपके प्रदाता को Living Security के egress IP addresses से आने वाले ट्रैफ़िक को स्वीकार करने के लिए कॉन्फ़िगर करना आवश्यक है, अन्यथा integration नेटवर्क स्तर पर अस्वीकार कर दिया जाएगा। इस पृष्ठ में वे addresses सूचीबद्ध हैं।

​
दो सेट हैं

Living Security दो अलग-अलग नेटवर्क के माध्यम से आपके प्रदाता तक पहुँचता है, और ये integration के अलग-अलग हिस्सों के लिए कार्य करते हैं। अधिकांश Integrations को केवल sync सेट की आवश्यकता होती है। एक विशिष्ट समूह को स्थायी रूप से दोनों की आवश्यकता होती है — देखें जिन Integrations को दोनों सेट चाहिए।

​
Integration sync traffic

ये चारों Living Security के प्रत्येक region के लिए समान हैं। EU में होस्ट किए गए ग्राहक वही चार addresses उपयोग करते हैं जो US में होस्ट किए गए ग्राहक करते हैं। उन प्रदाताओं के लिए जो अल्पविराम से अलग की गई सूची स्वीकार करते हैं:

​
Platform traffic

sync addresses के विपरीत, ये region-विशिष्ट हैं। केवल उसी region की जोड़ी का उपयोग करें जो आपके संगठन को होस्ट करता है। यदि आप निश्चित नहीं हैं कि वह कौन-सा region है, तो कुछ भी कॉन्फ़िगर करने से पहले अपने Customer Success Manager से पूछें — गलत region के addresses को allowlist करने पर integration ऐसे रूप में विफल रहता है जिसका allowlist से कोई संबंध नहीं दिखता। उन प्रदाताओं के लिए जो अल्पविराम से अलग की गई सूची स्वीकार करते हैं:

​
आउटबाउंड Playbook Actions

डिफ़ॉल्ट रूप से, जुड़े हुए सिस्टम में वापस लिखने वाले Playbook Actions उसी पथ से जाते हैं जिससे आपके डेटा sync होते हैं, इसलिए वे sync addresses से भेजे जाते हैं। किसी अतिरिक्त कार्रवाई की आवश्यकता नहीं है। कोई व्यवस्थापक किसी एक कनेक्शन को direct egress पर स्विच कर सकता है, जिससे उस कनेक्शन के Actions आपके region के platform addresses पर चले जाते हैं। यह सेटिंग ठीक इसी स्थिति के लिए है — ऐसा प्रदाता instance जो स्रोत IP द्वारा API एक्सेस को प्रतिबंधित करता है और जिसे allowlist करने के लिए एक छोटा, स्थिर, Living Security के स्वामित्व वाला सेट चाहिए। कुछ प्रदाता हमेशा direct egress का उपयोग करते हैं क्योंकि उन्हें प्रॉक्सी किया ही नहीं जा सकता। यदि आप केवल sync addresses को allowlist करते हैं और बाद में कोई कनेक्शन को direct egress पर स्विच कर देता है, तो उस कनेक्शन के Actions विफल होने लगते हैं जबकि उसके syncs चलते रहते हैं।

​
जिन Integrations को दोनों सेट चाहिए

अधिकांश Integrations के लिए, Living Security की integration सेवा स्वयं access token प्राप्त करती है और उसे नवीनीकृत करती है, और सब कुछ केवल sync addresses से आपके प्रदाता तक पहुँचता है। नीचे दिए गए Integrations के लिए वह सेवा token का नवीनीकरण नहीं कर सकती, इसलिए Living Security platform उसे सीधे जनरेट करता है — एक बार जब आप कनेक्ट करते हैं, और फिर जब तक कनेक्शन सक्रिय है तब तक लगातार। ये token अनुरोध platform addresses से भेजे जाते हैं। निर्धारित डेटा syncs अब भी sync addresses से भेजे जाते हैं।
कनेक्शन के पूरे जीवनकाल में दोनों सेट allowlisted रहने चाहिए। platform addresses केवल सेटअप के समय की आवश्यकता नहीं हैं। जब तक integration सक्रिय है, token नवीनीकरण एक छोटे चक्र पर चलता रहता है, इसलिए सफल सेटअप के बाद उन्हें हटाने पर अगली बार token की समय-सीमा समाप्त होते ही integration काम करना बंद कर देगा।
यदि आपके प्रदाता का token endpoint और उसका डेटा API एक ही host हैं — जो सामान्य है — तो उस एक host को दोनों नेटवर्क स्वीकार करने होंगे।

​
आवश्यक सेट के सभी addresses जोड़ें

ट्रैफ़िक किसी सेट के भीतर के किसी भी address से भेजा जा सकता है, और किसी अनुरोध के लिए कौन-सा उपयोग होगा यह निश्चित नहीं होता। केवल कुछ addresses को allowlist करने से रुक-रुक कर होने वाली विफलताएँ उत्पन्न होती हैं जिनका निदान कठिन होता है: कुछ अनुरोध सफल होते हैं, अन्य विफल, और यह पैटर्न कॉन्फ़िगरेशन से असंबंधित प्रतीत होता है। यह platform की जोड़ी पर उतना ही लागू होता है जितना sync के चार addresses पर। प्रत्येक region दो चलाता है, और अनुरोध किसी भी एक पर आते हैं।
ये addresses स्थिर हैं, लेकिन स्थायी नहीं हैं। हम इन्हें अपरिवर्तित रखने का प्रयास करते हैं, और इन्हें केवल कभी-कभार तथा असाधारण परिस्थितियों में बदलते हैं — जैसे हमारे अंतर्निहित इन्फ्रास्ट्रक्चर प्रदाता में परिवर्तन।चूँकि परिवर्तन संभव है, इस पृष्ठ को बुकमार्क करें। यदि पहले काम कर रहा कोई integration विफल होने लगे, तो सपोर्ट टिकट खोलने से पहले यहाँ लौटें और पुष्टि करें कि आपकी allowlist ऊपर दिए गए addresses से मेल खाती है।

​
किन Integrations के लिए यह आवश्यक है

IP allowlist आपके प्रदाता की एक सेटिंग है, Living Security की नहीं। यह केवल तभी लागू होती है जब आपके संगठन ने वह प्रतिबंध सक्षम किया हो। यदि आपने प्रदाता में IP प्रतिबंध सक्षम नहीं किए हैं, तो किसी कार्रवाई की आवश्यकता नहीं है। इन प्रदाताओं में यह सामान्यतः आवश्यक होता है: अन्य प्रदाता भी ऐसी ही सेटिंग प्रदान कर सकते हैं। Catalog में प्रदाता का पृष्ठ और प्रदाता के अपने दस्तावेज़ देखें।

​
अनुपस्थित या पुरानी allowlist के लक्षण

दोनों सेट विपरीत प्रकार से विफल होते हैं। कुछ भी बदलने से पहले लक्षण को सेट से मिलाएँ।

​
कनेक्शन सफल होता है, लेकिन डेटा कभी नहीं पहुँचता

यह अनुपस्थित sync address का संकेत है। क्रेडेंशियल कनेक्शन के समय ऐसे पथ से सत्यापित किए जाते हैं जो प्रायः उसी प्रतिबंध के अधीन नहीं होता, इसलिए Living Security में कनेक्शन डायलॉग सफलता की सूचना देता है। विफलता बाद में दिखाई देती है, जब निर्धारित sync चलता है और अवरुद्ध हो जाता है। इन्हें देखें:
  • कनेक्शन connected दिखता है, लेकिन streams कोई रिकॉर्ड नहीं दिखाते।
  • Sync रन 401 Unauthorized या 403 Forbidden के साथ विफल होते हैं।
  • महीनों से काम कर रहा integration आपकी ओर से कोई बदलाव किए बिना विफल होने लगता है।

​
कनेक्शन बिल्कुल बनाया नहीं जा सकता

यह अनुपस्थित platform address का संकेत है, और यह केवल जिन Integrations को दोनों सेट चाहिए में सूचीबद्ध Integrations पर लागू होता है। इन्हें देखें:
  • Access token प्राप्त करते समय सेटअप विफल होता है। कोई कनेक्शन नहीं बनता।
  • त्रुटि बताती है कि host तक पहुँचा नहीं जा सका, और उसके पीछे कोई HTTP प्रतिक्रिया नहीं है।
  • प्रदाता के अपने sign-in या Conditional Access लॉग में ऐसे address से अवरुद्ध अनुरोध दिखता है जिसे आपने allowlist नहीं किया है।
जिस कनेक्शन तक बिल्कुल पहुँचा नहीं जा सकता, वह क्रेडेंशियल की समस्या नहीं है। कोई प्रमाणीकरण हुआ ही नहीं, इसलिए secret बदलने या client credentials पुनः जनरेट करने से कोई लाभ नहीं होगा। allowlist में न जोड़ा गया स्रोत address इसका सबसे सामान्य कारण है, हालाँकि गलत host name, गलत port, या प्रदाता-पक्ष की आउटेज भी हमारी ओर से वैसी ही दिखती हैं।
आपकी allowlist में बाद का कोई परिवर्तन जो platform addresses को हटा देता है, एक अलग रूप में दिखता है: हफ़्तों से सही चल रहा integration कुछ ही मिनटों में बंद हो जाता है, क्योंकि अगला token नवीनीकरण अवरुद्ध हो जाता है।

​
यह Phishing simulation डिलीवरी को कवर नहीं करता

इस पृष्ठ के addresses integration ट्रैफ़िक पर लागू होते हैं — वे API कॉल जो Living Security डेटा आयात करने और Playbook Actions चलाने के लिए आपके जुड़े हुए सिस्टम पर करता है। Phishing simulation ईमेल डिलीवरी के लिए allowlisting एक अलग कॉन्फ़िगरेशन है, जिसके अपने addresses, प्रेषक डोमेन और डाउनलोड करने योग्य allowlist पैकेज हैं। इसे Settings → Phishing Simulation → Allowlisting में पूरा करें। उस प्रक्रिया के लिए Phishing Simulation settings देखें। इस पृष्ठ के addresses को allowlist करने से सिम्युलेटेड फ़िशिंग ईमेल डिलीवर नहीं होंगे, और simulation allowlisting पूरा करने से प्रतिबंधित प्रदाता API तक पहुँच संभव नहीं होगी। यदि आप दोनों का उपयोग करते हैं, तो दोनों कॉन्फ़िगर करें।

​
सहायता प्राप्त करना

यदि अपने region के addresses को allowlist करने के बाद भी Integrations विफल होते रहते हैं, तो अपने Customer Success Manager या support@livingsecurity.com से संपर्क करें। प्रदाता का नाम, विफल होने वाला stream या सेटअप का वह चरण जो विफल हुआ, और टाइमस्टैम्प शामिल करें, ताकि हम इसे अपने egress लॉग से मिला सकें।