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 प्रतिलिपि नगर्नुहोस्; यो क्लाइन्टले यो खाताका लागि लग गर्ने मान प्रयोग गर्नुहोस्, र जाँचेको मिति टिप्नुहोस्।

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