एउटै स्थिति बत्तीमा भर नगरी राउटर VPN निगरानी गर्नुहोस्
पियर स्थिति, चयन गरिएको मार्ग र अनुमति दिइएको अनुप्रयोग परीक्षणले फरक प्रश्नको जवाफ दिन्छन्। असफल भएको सीमामा अलार्म दिनुहोस्, हरियो आइकनमा होइन।
स्थिति पृष्ठले जडान भएको भन्छ, बत्ती हरियो छ, तर कार्यालय फाइल सर्भरसम्म पुग्न सक्दैन। यी तथ्यमध्ये एउटा टनेलको बारेमा हो र अर्को त्यसभित्रको बाटोको बारेमा। दुवैको निगरानी गर्नु भनेको तपाईंले कारबाही गर्न सक्ने चेतावनी र बेवास्ता गर्न सिक्ने चेतावनीबीचको फरक हो।
पाँच जाँच, क्रममा, पियरबाट बाहिरतिर।
जाँच 1: पियर वा एसोसिएसन स्थिति
हरेक प्रोटोकलले आफ्नै स्थिति देखाउँछ। WireGuard ले हरेक पियरका लागि नवीनतम ह्यान्डशेक र स्थानान्तरण काउन्टर wg show मार्फत देखाउँछ। OpenVPN ले सत्र स्थिति आफ्नो स्थिति फाइल वा व्यवस्थापन इन्टरफेसमा लेख्छ, र IPsec ले ipsec statusall जस्ता उपकरणमार्फत सुरक्षा एसोसिएसन देखाउँछ। जाल यो हो कि टाइमस्ट्याम्पलाई फैसला मानेर पढ्नु: पठाउन केही नभएको निष्क्रिय WireGuard पियरले हालै ह्यान्डशेक गर्दैन, र त्यो अवरोध होइन।
कसैलाई बोलाउनु अघि टाइमस्ट्याम्पलाई अपेक्षित ट्राफिक र keepalive सेटिङसँग तुलना गर्नुहोस्।
जाँच 2: चयन गरिएको मार्ग
टनेल इन्टरफेस हुन सक्छ तर त्यसमा केही पनि रुट हुँदैन। तपाईंलाई महत्त्वपूर्ण गन्तव्यका लागि फर्वार्डिङ तालिका जाँच्नुहोस्, टनेलको आफ्नै सबनेटका लागि होइन। यदि प्रिफिक्स छैन वा अन्तै संकेत गर्छ भने पियर स्थिति अप्रासंगिक हुन्छ।
त्यो जाँचले स्थिति बत्तीले कहिल्यै नदेखाउने खराबी समात्छ।
उपयोगी दोस्रो जाँचले स्रोत ठेगाना पनि तुलना गर्छ। ip route get 10.20.5.10 ले अर्को हप, इन्टरफेस र रुचाइएको स्रोत फर्काउँछ, र गलत स्रोत टाढाको छेउमा फिर्ता ट्राफिक तोड्न पर्याप्त हुन्छ। अपेक्षित त्रिक एक पटक लेख्नुहोस्, त्यसपछि कुनै पनि तत्व बदलिएमा अलार्म दिनुहोस्। त्यही एउटा लाइनले NAT परिवर्तन, इन्टरफेस अस्थिरता र नीति-आधारित रुटिङका गल्ती समात्छ।
जाँच 3: अनुमति दिइएको अनुप्रयोग मार्ग
वास्तविक आवश्यकताको प्रतिनिधित्व गर्ने कुरा परीक्षण गर्नुहोस्। राउटरबाट सुरु हुने पिङ राउटरको आफ्नै ठेगाना र नीतिबाट निस्कन्छ, जो फर्वार्ड गरिएको LAN ट्राफिकभन्दा फरक हुन सक्छ, र धेरै होस्टले ICMP सीमित गर्छन्। यदि आवश्यकता निजी सेवा हो भने त्यो सेवा यसको वास्तविक पोर्टमा परीक्षण गर्नुहोस्।
परीक्षणको मात्रा संयमित राख्नुहोस्। निगरानी लूप आफैंले नाप्ने ट्राफिक बन्नु हुँदैन।
जाँच 4: के बदलियो र कहिले
WAN परिवर्तन, कुञ्जी नवीकरण, मार्ग फिर्ता र अनुप्रयोग असफलतालाई एउटै समयरेखामा जोड्नुहोस्। टनेल असफलतालाई सामान्य इन्टरनेट पहुँच चुपचाप पुनर्स्थापित गर्ने फलब्याक मार्गबाट छुट्याउनुहोस्, किनकि दुवैले उस्तै प्रयोगकर्ता रिपोर्ट र विपरीत निदान दिन्छन्। टाइमजोन त्रुटिले क्रम उल्टाउँछ, त्यसैले तुलना अघि सामान्यीकरण गर्नुहोस्। चार जाँचलाई कारणमा बदल्ने कुरा समयरेखा नै हो।
लगहरू संक्रमणका लागि राख्नुहोस्, पेलोडका लागि होइन।
जाँच 5: अलार्मले सीमाको नाम लिनुपर्छ
VPN डाउन भन्ने अलार्मले आधा समय व्यक्तिलाई गलत ठाउँमा पठाउँछ। पियर ह्यान्डशेक बाह्र मिनेटदेखि पुरानो, 10.20.0.0/16 को मार्ग छैन, वा पोर्ट 445 मा परीक्षण असफल भन्ने अलार्मले विशिष्ट जाँचतिर संकेत गर्छ।
पेलोड ब्राउज गर्नुको सट्टा सञ्चालन काउन्टर राख्नुहोस्। काउन्टरले तपाईंलाई नचाहिने सामग्री नजम्मा गरी निगरानीको प्रश्नको जवाफ दिन्छ।
र अब के हुन्छ भन्ने फेलओभर नीतिले निर्णय गरोस्। निगरानीले कुन सीमा असफल भयो पहिचान गर्नुपर्छ, हरेक पटक परीक्षण असफल हुँदा व्यापक बाइपासलाई अनुमति दिनु हुँदैन। OpenVPN 2.6 पुस्तिका ले पहिलो जाँचलाई स्क्रिप्टयोग्य बनाउने स्थिति फाइल र व्यवस्थापन इन्टरफेसको दस्तावेजीकरण गर्छ।