सामग्री को कैप्चर किए बिना गिराए गए VPN पैकेट खोजें
नियम काउंटर और सीमित मेटाडेटा लॉगिंग उपयोगकर्ताओं द्वारा भेजी जाने वाली सामग्री को संग्रहीत किए बिना गिराए गए VPN प्रवाह का पता लगाते हैं। एक नए अनुरोध के लिए एक काउंटर डेल्टा की तुलना करें।
फ़ायरवॉल काउंटर तब बढ़ता है जब कोई पैकेट किसी नियम से मेल खाता है, और वह पैकेट को रखे बिना ऐसा करता है। अधिकांश ड्रॉप जाँचों में पहले प्रश्न का उत्तर देने के लिए यह पर्याप्त है: क्या प्रवाह इस नियम तक पहुँचा ही। पेलोड कैप्चर दूसरे प्रश्न का उत्तर देता है, और चलते समय इंटरफ़ेस पार करने वाली बाकी हर चीज़ इकट्ठा करता है। काउंटर से शुरू करें, और मेटाडेटा लॉगिंग पर केवल तब जाएँ जब काउंटर अस्पष्ट हो।
काउंटर पहले प्रश्न का उत्तर देते हैं
हर नियम जो मेल खा सकता है उसका एक काउंटर होता है, और परीक्षण से पहले और बाद में उसे पढ़ना बताता है कि ट्रैफ़िक पहुँचा या नहीं। यह संग्रह नहीं बल्कि दो संख्याओं की तुलना है, और इसका भंडारण या प्रदर्शन में कोई खर्च नहीं है।
काउंटर उस टूल से पढ़ें जिसके पास नियम हैं:
iptables -L FORWARD -v -n --line-numbers
nft list rulesetडेल्टा ही सबूत है। जिस नियम का काउंटर नहीं हिलता उसने प्रवाह को कभी नहीं देखा, जो किसी पहले की सीमा की ओर इशारा करता है: गलत इंटरफ़ेस, गलत तालिका, या ऐसा मार्ग जिसने पैकेट वहाँ कभी नहीं भेजा। जिस नियम का काउंटर हिलता है और फिर भी गिरा देता है वह बताता है कि नीति वही कर रही है जिसके लिए लिखी गई थी।
काउंटर आपको क्या नहीं बता सकता
काउंटर आपको संख्या देता है, कारण नहीं। वह पते पर मेल खाए पैकेट को पोर्ट पर मेल खाए पैकेट से अलग नहीं कर सकता, और यह नहीं बता सकता कि दो समान नियमों में से किसने प्रवाह पकड़ा। यह यह भी नहीं बता सकता कि पैकेट गिराया गया, अस्वीकार किया गया या स्वीकार करके बाद में खो गया, जब तक आप उस नियम को न पढ़ें जिसके पास काउंटर है।
यहीं मेटाडेटा लॉगिंग आती है, और दायरा ही पूरी बात है। किसी विशेष परीक्षण प्रवाह के लिए इंटरफ़ेस, दिशा, पते, प्रोटोकॉल और फैसला लॉग करें। वे फ़ील्ड उपयोगकर्ता क्या कर रहा था यह दर्ज किए बिना विफल सीमा का पता लगाते हैं।
पेलोड लॉगिंग दूसरे प्रश्न का उत्तर देती है, और वह इंटरफ़ेस पर सभी के बारे में देती है।
संकीर्ण दायरे के साथ मेटाडेटा लॉगिंग
ऐसा नियम लिखें जो केवल आपके परीक्षण प्रवाह से मेल खाए, उसे एक अलग पहचानने योग्य उपसर्ग दें, और प्लेटफ़ॉर्म के अपने नियंत्रणों के अंतर्गत उसकी दर सीमित करें ताकि साधारण पुनःप्रयास भंडारण को भर न दे। उपसर्ग ही वह चीज़ है जो आपको डिवाइस द्वारा लॉग की जाने वाली बाकी हर चीज़ के बीच अपनी प्रविष्टियाँ खोजने देता है।
केवल इसलिए कि सुविधा मौजूद है, पेलोड या अप्रतिबंधित पैकेट लॉगिंग सक्षम करने से बचें। कटा हुआ कैप्चर भी स्वतः पेलोड-मुक्त नहीं होता, क्योंकि हेडर के आकार और पैकेट के लेआउट बदलते हैं, इसलिए छोटा दिखने वाला स्नैप लंबाई भी एप्लिकेशन बाइट्स ले जा सकता है।
यदि कैप्चर करना ही हो, तो एक प्रवाह, सीमित समय के लिए, उस सबसे छोटी स्नैप लंबाई के साथ कैप्चर करें जो आपके प्रश्न का उत्तर दे।
एक नए अनुरोध से मेल करें
वास्तविक क्लाइंट मार्ग का पालन करने वाला हानिरहित ट्रैफ़िक उत्पन्न करें, फिर संबंधित काउंटरों की पहले और बाद में तुलना करें। गेटवे पर स्थानीय परीक्षण फ़ॉरवर्डिंग नियम को पूरी तरह चूक सकता है, क्योंकि पैकेट कभी फ़ॉरवर्डिंग पथ नहीं लेता। स्थापित सत्र भी नए कनेक्शन से भिन्न स्थिति-प्रबंधन से मेल खा सकता है, इसलिए दीर्घकालिक प्रवाह नए का विकल्प नहीं है।
विंडो को समय-सीमा में रखें और उसे लिख लें। दो निर्दिष्ट मिनटों के बीच, इस क्लाइंट पते से, इस प्रोटोकॉल पर इस गंतव्य तक — यह निदान है। आज सुबह कभी — यह खोज है।
एक प्रवाह, एक विंडो, एक सीमा यहाँ प्रगति की इकाई है।
सफ़ाई करें और केवल अंश रखें
जाँच समाप्त होते ही स्वामी कॉन्फ़िगरेशन के माध्यम से अस्थायी निदान नियम हटा दें। जगह पर छोड़ा गया संकीर्ण लॉगिंग नियम अनजाने रिकॉर्ड सिस्टम में बदल जाता है, और छह महीने बाद किसी को याद नहीं रहता कि वह क्यों मौजूद है।
नीति की माँग हो तो मूल रिकॉर्ड निजी रखें, और पूरे कैप्चर के बजाय समीक्षित न्यूनतम अंश साझा करें। पेलोड न होने पर भी पते, खाता पहचानकर्ता और आंतरिक टोपोलॉजी संवेदनशील हैं। अंश को स्वामी वाले दस्तावेज़ की तरह मानें। जो निदान को नहीं चाहिए उसे छिपा दें।
लक्ष्य एक विशिष्ट अनुरोध के लिए एक विशिष्ट विफल सीमा है। VPN का उपयोग करने वाले हर व्यक्ति का पूरा संग्रह बनाने वाली कोई भी चीज़ निदान से आगे बढ़कर दूसरा प्रोजेक्ट शुरू कर चुकी है। कुछ जोड़ने से पहले प्लेटफ़ॉर्म के लॉगिंग दस्तावेज़ में देखें कि वह डिफ़ॉल्ट रूप से क्या रिकॉर्ड करता है।