VPN लगले ब्राउजिङबारे के प्रमाणित गर्न सक्छ र के सक्दैन

लग सङ्कलक छान्नुअघि अडिटले कुन घटना स्थापित गर्नुपर्ने हो भन्ने तय गर्नुहोस्। कुन VPN सत्रले गन्तव्य ठेगानासँग सम्पर्क गर्यो भनी सोध्नु, कुन व्यक्तिले कुनै निश्चित पृष्ठ खोल्यो भनी सोध्नुभन्दा फरक प्रश्न हो। दुवैलाई फरक रेकर्ड, फरक जोडाइ र फरक विश्वास स्तर चाहिन्छ। OpenVPN जडान लगले पहिलोको जवाफ दिन्छ र दोस्रोको दिन सक्दैन।

सङ्कलक छान्नुअघि घटनाको नाम राख्नुहोस्

सत्र रेकर्डले स्वीकृत पहिचान, सुरु र अन्त्यको समय र सर्भरले आफ्नै नीतिअनुसार तोकेको ठेगाना देखाउँछ। रिजोल्भर लगले त्यो रिजोल्भरमा नाम सोधिएको देखाउँछ। प्रवाह रेकर्डले ठेगाना, पोर्ट, प्रोटोकल र समय देखाउँछ, र अनुप्रयोग लगले त्यो अनुप्रयोगले वास्तवमै ह्यान्डल गरेको कारोबार देखाउँछ। यी चारमध्ये कुनै पनि अर्कोको विकल्प होइन।

तीमध्ये प्रत्येकले एउटा घटना स्थापित गर्छ र बाँकी खुला राख्छ। प्रश्न पहिले लेख्नुले डाटाले समर्थन गर्न नसक्ने कथा जोड्नबाट रोक्छ।

journalctl -u [email protected] --since today | grep -i 'peer info\|assigned'
cat /etc/openvpn/server/openvpn-status.log | head -20
conntrack -L -p tcp --dport 443 2>/dev/null | head -20

पहिलो आदेशले सेवा जर्नलबाट सत्र घटना देखाउँछ। दोस्रोले तोकिएका ठेगानासहित हालको ग्राहक सूची छाप्छ, जुन त्यो म्यापिङ हो जसमा अडिट जोडाइ निर्भर छ। तेस्रोले जडान रहुन्जेल मात्र उपयोगी प्रत्यक्ष प्रवाह स्थिति देखाउँछ।

खोज भ्रमण होइन

ब्राउजरले नामहरू अनुमानका आधारमा समाधान गर्छ, जवाफ क्यास गर्छ र निगरानी गरिएको रिजोल्भरलाई फेरि नसोधी तिनको पुनःप्रयोग गर्छ। त्यसैले रिजोल्भर लगमा रहेको नामले खोज प्रमाणित गर्छ, भ्रमण होइन। HTTPS माथिको DNS यो खाडल फराकिलो बनाउँछ, किनकि त्यसका लागि कन्फिगर गरिएको ब्राउजरले आफ्ना प्रश्नहरू तपाईंको साधारण लगरले कहिल्यै नदेख्ने ठाउँमा पठाउँछ।

गन्तव्य ठेगाना आफैंमा राम्रो हुँदैनन्। एउटा ठेगानाले धेरै असम्बन्धित साइट होस्ट गर्न सक्छ, रिभर्स DNS पुनर्निर्माण नभई अनुमान हो, र TLS ह्यान्डसेकका क्रममा देखिने होस्टनाम इन्क्रिप्टेड सत्रभित्रको अनुरोध मार्ग होइन।

सटीक कारोबारका लागि तपाईंलाई अनुप्रयोगका आफ्नै घटना रेकर्ड वा लगिङका लागि स्पष्ट रूपमा समर्थित प्रोक्सी ढाँचा चाहिन्छ। CONNECT सुरुङले प्रोक्सीलाई गन्तव्य र मात्रा दिन्छ, भित्रका पृष्ठ मार्ग दिँदैन। सञ्जालमा प्रशासनिक पहुँच अनुप्रयोगको विश्वास मोडेल चुपचाप बदल्ने इजाजतपत्र होइन।

व्यक्तिको नाम लिनुअघि पहिचान र समय जोड्नुहोस्

आन्तरिक स्रोत ठेगाना बोकेको प्रवाह रेकर्डको कुनै अर्थ हुँदैन जबसम्म त्यो ठेगाना एउटै समयमा सत्रसँग जोडिँदैन। ठेगाना पुनःप्रयोग हुन्छन्, र त्यही ठेगाना एक घण्टा अघि अर्को सत्रको हुन सक्थ्यो। स्थिर बाँडफाँट सम्बन्ध कायम राख्ने एउटा तरिका हो, एकमात्र होइन।

अनुवादका सीमाले जोडाइ अझ कमजोर बनाउँछ। यदि धेरै उपकरणले तपाईंको अवलोकन बिन्दुअघि नै एउटै स्रोत ठेगाना साझा गरेका थिए भने तपाईंले पहिचान गर्न सक्ने उत्तम कुरा एउटा उपकरण होइन, साझा गेटवे सत्र हो। धेरै व्यक्तिले प्रयोग गर्ने प्रमाणपत्र वा खाताको पनि त्यही प्रभाव हुन्छ।

समय क्षेत्र, घडीका स्रोत, अवलोकन बिन्दु र प्रत्येक अनुवाद चरण रेकर्ड गर्नुहोस्। छुटेका रेकर्डको अर्थ प्रवाह प्रविष्टि पुरानो भयो, सेन्सर छलियो वा अनुप्रयोग लग बन्द थियो हुन सक्छ। अनुपस्थिति केही भएन भन्ने प्रमाण होइन।

त्यसपछि घोषित उद्देश्यका लागि न्यूनतम क्षेत्र, अनुमति प्राप्त पाठक र अवधारण अवधि परिभाषित गर्नुहोस्। सहसम्बन्ध र गलत आरोपण पछिको सोच नभई डिजाइनका प्रश्न हुन्, र व्यक्ति पहिचान गर्ने मेटाडाटा त्यसले भर पर्ने पहिचान म्यापिङजत्तिकै संरक्षणको योग्य छ।

तपाईंले नियन्त्रण गर्ने गतिविधिले अडिट परीक्षण गर्नुहोस्

जसको सत्र र अनुप्रयोग तपाईंलाई पहिल्यै थाहा छ त्यस्तो अनुमति प्राप्त ट्राफिक उत्पन्न गर्नुहोस्, त्यसपछि प्रत्येक रेकर्डले वास्तवमै के समात्यो जाँच्नुहोस्। पृष्ठ नलोड गरी खोज गर्नुहोस्, क्यासबाट पृष्ठ लोड गर्नुहोस् र प्रोक्सीमार्फत जडान खोल्नुहोस्, र कुन घटना देखिन्छन् हेर्नुहोस्।

प्रमाणले समर्थन गर्ने घटना रिपोर्ट गर्नुहोस् र यसले के समेट्दैन भन्नुहोस्। घोषित क्षेत्रसहितको साधारण रेकर्ड समीक्षामा टिक्छ; अनुमानबाट जोडिएको महत्त्वाकांक्षी ब्राउजिङ इतिहास टिक्दैन।