एक स्टेटस लाइट पर भरोसा किए बिना राउटर 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 मैनुअल स्टेटस फ़ाइल और प्रबंधन इंटरफ़ेस का दस्तावेज़ीकरण करता है जो पहली जाँच को स्क्रिप्ट-योग्य बनाते हैं।