समस्या
इस लेख में वर्णन किया गया है कि क्यों, एक ही गंतव्य पर जाने के बावजूद, कुछ कनेक्शन Cato द्वारा अवरोधित किए जाते हैं जबकि अन्य की अनुमति दी जाती है।
उदाहरण के लिए, नीचे की घटना खोज में यह दर्शाया गया है कि किस प्रकार एक ही स्रोत ने एक ही गंतव्य IP और प्रोटोकॉल पर कनेक्ट करने की कोशिश की। हालांकि, जबकि एक कनेक्शन को अवरुद्ध किया गया था, दूसरे को अनुमति दी गई थी।

ट्रबलशूटिंग
इस खंड में, हम कई सामान्य परिदृश्यों की खोज करेंगे जो कि कनेक्शन को Cato द्वारा अलग ढंग से व्यवहार करने के लिए कारण बन सकते हैं। इन परिदृश्यों को समझना प्रभावी रूप से कनेक्शन को अनुकूलित और समस्या निवारण करने के लिए आवश्यक है। आइए नीचे उनमें से प्रत्येक में गहनतापूर्वक जाएं।
1. असममित रूटिंग
जब Cato के पास पूर्ण प्रवाह की दृश्यता नहीं होती है, तो वह उपयुक्त एप्लिकेशन में डेटा को सही ढंग से श्रेणीकृत करने के लिए पर्याप्त जानकारी की कमी कर सकता है। परिणामस्वरूप, भले ही HTTPS जैसे विशिष्ट प्रोटोकॉल की अनुमति दी गई हो, असमान रूटिंग के कारण प्रवाह को गलती से TCP के रूप में श्रेणीबद्ध किया जा सकता है। दुर्भाग्य से, यह गलत श्रेणीकरण कनेक्शन को अवरुद्ध कर सकता है क्योंकि यह अनुमत फ़ायरवॉल नियम के अनुकूल नहीं है। और जांच करने के लिए, यह अनुशंसा की जाती है कि समस्या होने पर स्रोत से गंतव्य और इसके विपरीत दोनों दिशा में ट्रेसरूट करें। अग्रणी और प्रतिवर्ती मार्गों की तुलना करके, हम जांच सकते हैं कि क्या यह वास्तव में समस्या का कारण है।
2. ओवरलैपिंग कस्टम एप्लीकेशन
जब प्रभावित कनेक्शन में एक कस्टम एप्लिकेशन शामिल होता है, तो इसके परिभाषा की गहन जांच करना महत्वपूर्ण है। एक अत्यधिक सरलीकृत कस्टम एप्लिकेशन की परिभाषा Cato को एप्लिकेशन को असंगत रूप से पहचानने का कारण बन सकती है। यदि एक फ़ायरवॉल नियम कस्टम एप्लिकेशन के लिए कनेक्शन की अनुमति देता है, लेकिन कस्टम एप्लिकेशन की परिभाषा के कारण इसकी पहचान असंगत हो जाती है, जो कनेक्शन के प्रवाह के असंगत अवरोध का कारण बनती है। इसलिए, जब कस्टम अनुप्रयोगों के लिए कनेक्शनों का संचालन होता है, तो हम सुझाव देते हैं कि कस्टम अनुप्रयोगों के साथ कार्य करना में उल्लिखित सर्वोत्तम प्रथाओं का पालन करें ताकि स्थिर व्यवहार सुनिश्चित हो सके।
3. उपयोगकर्ता जागरूकता में देरी
जब कोई उपयोगकर्ता प्रारंभिक रूप से Cato नेटवर्क द्वारा कनेक्ट होता है, तब AD-आधारित और Identity-Agent-आधारित उपयोगकर्ता जागरूकता तंत्र स्रोत IP पता को संबंधित उपयोगकर्ता नाम से मैप करने में कुछ सेकंड लगते हैं। इस संक्षिप्त अवधि के दौरान, प्रारंभिक उपयोगकर्ता ट्रैफिक को एक अप्रत्याशित फ़ायरवॉल नियम के तहत संसाधित किया जा सकता है। हालांकि, एक बार उपयोगकर्ता जागरूकता उपयोगकर्ता नाम की सफल पहचान कर लेता है, उपयुक्त फ़ायरवॉल नियम प्रभावी हो जाएगा।
4. ऐप पहचान टाइमआउट (HTTP/1.1)
आधुनिक ब्राउज़र अनेक TCP कनेक्शन को एक साथ HTTP/1.1 के माध्यम से खोलते हैं ताकि पृष्ठ लोड प्रदर्शन में सुधार हो सके। इनमें से कुछ कनेक्शन स्थापित किए जाने के बाद थोड़ी देर के लिए निष्क्रिय रहते हैं — कोई HTTP अनुरोध तुरंत नहीं भेजा जाता है, जिसका अर्थ है कि गंतव्य होस्टनाम अभी दिखाई नहीं दे रहा है। जब Cato ट्रैफ़िक को एक सॉकेट साइट के माध्यम से प्रोसेस करता है, तो वह आते ही प्रत्येक कनेक्शन का मूल्यांकन करता है। यदि मूल्यांकन के समय गंतव्य होस्ट नाम मौजूद नहीं है, तो ट्रैफ़िक किसी भी फ़ायरवॉल नियम से मेल नहीं खाएगा जो एक पूर्ण डोमेन नाम (FQDN) या डोमेन का मिलान शर्त के रूप में उपयोग करता है, भले ही ऐसा नियम सही तरीके से विन्यस्त किया गया हो।
यह अपेक्षित व्यवहार है और यह सॉकेट साइट (ऑफिस मोड) के माध्यम से प्रोसेस किए जाने वाले HTTP/1.1 ट्रैफ़िक के लिए विशिष्ट है। यह SDP क्लाइंट के साथ नहीं होता है, जो ट्रैफ़िक अग्रेषित होने से पहले गंतव्य संदर्भ प्रदान करता है। नीचे वे शर्तें हैं जो इस समस्या को पैदा कर सकती हैं:
केवल HTTP वेबसाइट
ब्राउज़र एक अतिरिक्त TCP कनेक्शन खोलता है (HTTP/1.1 व्यवहार — Chrome 6 तक समानांतर कनेक्शन खोलता है)।
कोई HTTP GET उस अतिरिक्त कनेक्शन पर 1 सेकंड के भीतर नहीं भेजा जाता है।
सुझाव समाधान
यदि आप Firefox का उपयोग कर रहे हैं, तो
network.http.max-persistent-connections-per-serverकोabout:configके तहत 1 पर सेट करें।फ़ायरवॉल नियम को अपडेट करें ताकि गंतव्य IP पते का उपयोग FQDN/डोमेन के बजाय किया जा सके।
वैकल्पिक रूप से, यदि गंतव्य सर्वर इसका समर्थन करता है, तो HTTP/2 इस व्यवहार को समाप्त करता है क्योंकि यह एक ही मल्टीप्लेक्स कनेक्शन का उपयोग करता है और खाली समानांतर TCP कनेक्शन नहीं खोलता है।
5. नियम में FQDN
एक और सामान्य परिदृश्य जहाँ भ्रमित दिखने वाले कनेक्शन को Cato द्वारा अलग तरीके से प्रबंधित किया जाता है (अवरुद्ध या अनुमत), वह है जब फ़ायरवॉल नियमों या कस्टम श्रेणी/एप्लिकेशन में पूर्ण क्वालिफाइड डोमेन नाम (FQDN) का उपयोग किया जाता है। विवरण में जाने से पहले, चलिए दो घटनाओं की जांच करते हैं, दोनों ही एक ही स्रोत IP पते से आ रही हैं और एक ही IP पते और पोर्ट पर जा रही हैं, लेकिन विभिन्न परिणामों के साथ - एक अनुमत और दूसरा अवरुद्ध।

फ़ायरवॉल नियमों की समीक्षा करें
दिए गए उदाहरण में, कनेक्शन को WAN फ़ायरवॉल नियम के आधार पर या तो अवरुद्ध या अनुमति दी जाती है।
और जांच करने के लिए, इन चरणों का पालन करें:
CMA के भीतर WAN फ़ायरवॉल अनुभाग पर जाएं और संबंधित नियमों को खोजें।
यह स्पष्ट हो जाता है कि नियम 1 मॉनिटर (अनुमति) घटना से संबंधित है। यह नियम विशेष रूप से "आंतरिक वेब सर्वर" के तहत वर्गीकृत कनेक्शन की अनुमति देता है। नियम पर क्लिक करने से पता चलता है कि "आंतरिक वेब सर्वर" कस्टम श्रेणी से आया है।
इसके विपरीत, नियम 5 अवरोध घटना के साथ मेल खाता है। यह HTTP(s) ट्रैफ़िक के साथ-साथ अन्य सेवाओं को अवरुद्ध करने के लिए डिज़ाइन किया गया है।

ऐप/श्रेणी की समीक्षा करें
अब जब हमने फ़ायरवॉल नियम से निर्धारित किया है कि "आंतरिक वेब सर्वर" कस्टम श्रेणी से मेल खाने के आधार पर कनेक्शन की अनुमति दी गई थी, आइए इस मेल के लिए स्थिति को समझने के लिए और अधिक जांच करें।
संसाधन पर नेविगेट करें > श्रेणियाँ > कस्टम श्रेणियाँ
कस्टम श्रेणियों की सूची में, "आंतरिक वेब सर्वर" श्रेणी को ढूंढें और चुनें।
श्रेणी विवरण के भीतर, यह देखा जाता है कि "आंतरिक वेब सर्वर" श्रेणी का सदस्य webserver.dyow-homelab.com के पूर्ण क्वालिफाइड डोमेन नाम (FQDN) से मेल खाता है।
यह दर्शाता है कि पूर्ण क्वालिफाइड डोमेन नाम (FQDN) से मेल खाते कनेक्शन अनुमत किए जाएंगे। (होस्ट का नाम सही ढंग से पहचानने के लिए, हमें DNS प्रश्न/प्रतिक्रिया देखना आवश्यक है)

कोई भी कनेक्शन जो सही पूर्ण क्वालिफाइड डोमेन नाम से मेल नहीं खाता है, उसे अस्वीकृत कर दिया जाएगा। उदाहरण के लिए, यदि देखी गई वेबसाइट में "www" शामिल है, वह www.webserver.dyow-homelab.com (जैसा कि DNS क्वेरी के अनुसार) परिभाषित पूर्ण डोमेन नाम (FQDN) के साथ CMA में मिलान नहीं करेगा। इस समस्या को हल करने के लिए, इसके बजाय एक डोमेन वस्तु को परिभाषित किया जा सकता है। यह परिभाषित डोमेन को शामिल करने वाले सभी सबडोमेन्स से मेल खाने की अनुमति देगा। देखें Cato WAN फायरवॉल।

उपर्युक्त अवरुद्ध कनेक्शन उदाहरण में, उपयोगकर्ता ने इसके पूर्ण क्वालिफाइड डोमेन नाम के बजाय इसके गंतव्य IP पते का उपयोग करके सर्वर को एक्सेस करने का प्रयास किया। इस मामले में, चूंकि कोई DNS प्रश्न/प्रतिक्रिया नहीं थी, Cato होस्ट का नाम पहचानने में सक्षम नहीं था, और नियम मेल नहीं खाया।
ऐसे मामलों में जहाँ बिना पूर्ववर्ती DNS अनुरोध के सीधे IP एक्सेस होता है, Cato अपने DNS कैश का उपयोग करके दिए गए IP से डोमेन को मेल करने का प्रयास करता है। यदि कैश में कोई डोमेन नहीं है, तो Cato इसे एक होस्ट का नाम या पूर्ण क्वालिफाइड डोमेन नाम के साथ जोड़ने में असमर्थ होगा। परिणामस्वरूप, उपरोक्त उदाहरण में कनेक्शन अवरुद्ध कर दिया जाएगा।
इसलिए, जब पूर्ण डोमेन नाम (FQDN) के आधार पर मिलान के लिए अनुमति दें फ़ायरवॉल नियम सक्रिय होता है, तो ग्राहक को निर्बाध कनेक्टिविटी सुनिश्चित करने के लिए अपने डोमेन नाम का उपयोग करके सर्वर तक पहुँच प्राप्त करनी चाहिए।
नोट:
यदि आप एक आंतरिक DNS सर्वर का उपयोग कर रहे हैं, तो सुनिश्चित करें कि सभी इसके DNS प्रश्न काटो क्लाउड के माध्यम से रूट किए गए हैं, भले ही गंतव्य DNS सर्वर कॉन्फ़िगर किया गया हो। DNS की सर्वोत्तम प्रथाओं के लिए, देखें Best-Practices-for-DNS-and-Your-Cato-Account
वैकल्पिक समाधान
ऐसे मामलों में जहाँ फ़ायरवॉल नियम के असंगति बनी रहती हैं, यहाँ तक कि जब साइट को इसके डोमेन नाम का उपयोग करके एक्सेस किया जा रहा है और DNS प्रश्न/प्रतिक्रिया वास्तव में Cato के माध्यम से जा रहे हैं, निम्नलिखित समाधान लागू किए जा सकते हैं;
उपयोगकर्ता के पीसी पर DNS कैश PoP पर DNS कैश से भिन्न हो सकता है जो Cato को सर्वर का IP पते को पूर्ण क्वालिफाइड डोमेन नाम के साथ जोड़ने से रोक सकता है। जिन मामलों में आंतरिक DNS सर्वर का उपयोग किया जा रहा है, DNS TTL (जीवन-काल) को छोटा किया जा सकता है और इसलिए पीसी को DNS प्रश्न अधिक बार उत्पन्न करने के लिए मजबूर करता है।
उस फ़ायरवॉल नियम में उपयोग किए गए कस्टम ऐप/श्रेणी में IP/पोर्ट संयोजन का उपयोग करें जो सर्वर से मेल खाता है। उपरोक्त उदाहरण में, कस्टम ऐप को IP पता 192.168.2.25 और पोर्ट 8080 पर सेट करें। यह दृढ़ करेगा कि नियम मेल खाएगा चाहे DNS कैश असंगत हो या Cato Cloud पर DNS प्रश्न अनुपलब्ध हों।