Linux पर Kerio: kvnet को वह MAC देना जिसकी सर्वर अपेक्षा करता है

Kerio सुरंग के ट्रैफ़िक ले जाने से पहले तीन चीज़ें सहमत होनी चाहिए: kvnet इंटरफ़ेस पर पता, क्लाइंट द्वारा लॉग किया गया मान, और जिसकी सर्वर नीति या DHCP अपेक्षा करता है। जब वे सहमत नहीं होते, सुरंग फिर भी प्रमाणित होती है और फिर भी ऊपर आती है, और यही विफलता को उलझनभरा बनाता है। इंटरफ़ेस हर कनेक्शन के लिए बनाया जाता है, इसलिए हाथ से सेट किया गया पता उसी सत्र का है और किसी और का नहीं। समस्या का आकार यही है, और समाधान कॉन्फ़िगरेशन फ़ाइल नहीं बल्कि एक हुक है। बाकी यह है कि मान कहाँ से पढ़ना है और कहाँ लागू करना है।

पता बार-बार वापस क्यों आता है

kvnet एक वर्चुअल अडैप्टर है जिसे क्लाइंट कनेक्शन शुरू होने पर बनाता है और समाप्त होने पर हटा देता है। इसलिए एक मैन्युअल ip link set ठीक उतनी ही देर टिकता है जितनी वह सत्र टिकता है जिस पर वह लागू किया गया था, और अगला कनेक्शन वहीं से शुरू होता है जो क्लाइंट आवंटित करता है। जिस मशीन पर क्लाइंट अपेक्षित पता लागू करने में विफल रहता है, वहाँ हर पुनःकनेक्शन वही असामंजस्य फिर ले आता है, और लीज़ या पहुँच नियम डिवाइस को फिर अस्वीकार कर देता है।

यह पैटर्न अपने आप में नैदानिक है। एक सत्र में काम करने वाली और अगले में विफल होने वाली सुरंग क्रेडेंशियल की समस्या नहीं है, क्योंकि कनेक्शनों के बीच क्रेडेंशियल नहीं बदलते।

मान इंटरफ़ेस से नहीं, क्लाइंट से पढ़ें

Linux क्लाइंट बातचीत का विवरण अपने डिबग लॉग में लिखता है, और जो पता वह उपयोग करना चाहता है वह वहाँ कनेक्शन अनुक्रम के अंतिम पता-आकार के टोकन के रूप में दिखता है। इसकी तुलना उससे करें जो कर्नेल वास्तव में रखता है, जो एक readlink दूर है: cat /sys/class/net/kvnet/address।

यदि दोनों भिन्न हैं, तो क्लाइंट सही मान जानता था और उसे लागू करने में विफल रहा, और इंटरफ़ेस बनने के बाद उसे लागू करने वाला हुक यह अंतर पाट देता है। यदि लॉग में कोई पता ही नहीं है, तो समस्या पहले की है और स्क्रिप्ट की नहीं, क्लाइंट संस्करण या सर्वर प्रोफ़ाइल की है।

इंटरफ़ेस बनने के बाद इसे लागू करें

NetworkManager के उपयोगकर्ता इसकी डिस्पैचर निर्देशिका में स्क्रिप्ट डाल सकते हैं और केवल तभी कार्य कर सकते हैं जब VPN इंटरफ़ेस ऊपर आए। systemd द्वारा प्रबंधित क्लाइंट को अधिक सावधानी चाहिए: सेवा शुरू होने पर चलने वाला drop-in सामान्यतः अडैप्टर बनने से पहले सक्रिय होता है, इसलिए हुक को अडैप्टर मान लेने के बजाय इंटरफ़ेस की प्रतीक्षा करनी चाहिए। तब पता सेट करें, और यदि लिंक ऊपर रहते हुए कर्नेल मना करे, तो उसे नीचे लाएँ, पता सेट करें और फिर ऊपर लाएँ। निकाले गए टोकन को ip link को देने से पहले MAC पैटर्न के माध्यम से फिर पढ़ें, ताकि कोई अप्रत्याशित लॉग पंक्ति तर्क न बन सके।

क्लाइंट के लॉग से root के रूप में चलने वाली कोई भी चीज़ संकीर्ण स्वामित्व की हकदार है: root के स्वामित्व वाली फ़ाइल, दूसरों द्वारा लिखी न जा सकने वाली, और सत्यापित पते से आगे कोई शेल इंटरपोलेशन नहीं। पैटर्न जाँच स्क्रिप्ट के अंदर ही रखें। लॉग की सामग्री को यह तय करने न दें कि कौन-सा आदेश चलेगा।

लिंक के बजाय लीज़ सत्यापित करें

ip -4 -o addr show dev kvnet को अपेक्षित परिसर में पता दिखाना चाहिए, ip neigh show dev kvnet को गेटवे दिखाना चाहिए, और VPN के पीछे की एक सेवा को उत्तर देना चाहिए। फिर एक बार डिस्कनेक्ट करें और पुनः कनेक्ट करें; यदि पता वापस आता है, तो हुक गलत घटना पर चल रहा है या बिल्कुल नहीं चल रहा।

जो इंटरफ़ेस सही पते के साथ दिखता है और कभी लीज़ नहीं पाता, वह सर्वर पक्ष की ओर संकेत करता है। यह दूसरी जाँच है और सामान्यतः दूसरी टीम। हुक को फिर से संपादित करने से पहले पुष्टि करें कि खाता अनुमत है और पूल के पास अभी भी पता है।

अपग्रेड के बाद वर्कअराउंड पर फिर विचार करें

जो क्लाइंट बिल्ड पता सही ढंग से सेट करता है, वह आपके हुक को पुराना मान लागू करते रहने देता है, जो किसी सुधार द्वारा लाई गई नई खराबी है। दूसरी मशीन या फ़ोरम पोस्ट से भी कभी MAC की नकल न करें; इस क्लाइंट द्वारा इस खाते के लिए लॉग किया गया मान उपयोग करें, और जिस तारीख को आपने इसे सत्यापित किया उसे दर्ज करें।

स्क्रिप्ट को इतना छोटा रखें कि एक बैठक में पढ़ा जा सके। लॉग पार्स करने वाले वर्कअराउंड स्वभाव से अस्थायी होते हैं। जो टिकते हैं वे वही हैं जिन्हें भविष्य का पाठक मूल थ्रेड के बिना समझ सके।