तुमचा VPN लॉग पाठवण्यापूर्वी वाचा: फील्डनुसार
सपोर्ट लॉगमध्ये वापरकर्तानावे, प्रमाणपत्राची नावे, अंतर्गत पत्ते आणि कधीकधी एक की असते. फील्ड तपासा, गुपिते शोधा, नंतर संपादित उतारा पाठवा.
तुम्ही सपोर्ट तिकीट उघडता, क्लायंटने तयार केलेला डायग्नोस्टिक एक्सपोर्ट जोडता आणि थांबता। फाइलमध्ये कदाचित ब्राउझिंग इतिहास अजिबात नसेल, आणि त्यामुळेच ती सुरक्षित वाटते। तरीही त्यात तुम्ही कोण आहात, कोणते मशीन वापरले, कोणत्या अंतर्गत पत्त्यांवर आणि कधी पोहोचलात, आणि कधीकधी स्वतःची कॉन्फिगरेशन लॉग करणाऱ्या क्लायंटने कॉपी केलेली खाजगी की असते। पाठवण्यापूर्वी फाइलमधून जाण्यास सुमारे पाच मिनिटे लागतात आणि कायमचे उघड होणे टाळते।
ते उघडा आणि पहिल्या चाळीस ओळी वाचा
वरून सुरुवात करा, जिथे क्लायंट सहसा आवृत्ती, प्लॅटफॉर्म आणि कॉन्फिगरेशन ओततात। पहिल्या ओळी फाइल किती तपशीलवार आहे हे सांगतात, आणि त्यावरून उर्वरित किती लक्ष द्यायचे ते ठरते। डीफॉल्ट लॉग आणि डीबग लॉग वेगळ्या प्रदर्शनासह वेगळ्या वस्तू आहेत।
head -n 40 vpn-support.log
sed -n '1,40p' vpn-support.log | grep -nE 'version|platform|config|option'
त्यातील काहीही वाचण्यापूर्वी फाइलचा आकार आणि आकारही तपासा। एकच घटना पुनरावृत्ती होणारी दोन मेगाबाइटची मजकूर फाइल छाटणे सोपे आहे। त्याच फोल्डरमधील बायनरी कॅप्चर पूर्णपणे वेगळी समस्या आहे, आणि त्यासाठी एक्सपोर्ट मागणाऱ्याशी वेगळा संवाद हवा।
Windows वर समतुल्य प्रत्येकी एक cmdlet आहे, आणि पहिली तुम्ही स्वतः तयार न केलेल्या कोणत्याही फाइलवर चालवणे योग्य आहे:
Get-Content .\vpn-support.txt -TotalCount 40
Get-Item .\vpn-support.txt | Select-Object Length,LastWriteTime
व्यक्ती ओळखणारी फील्ड
वापरकर्तानावे अशा ठिकाणी दिसतात जिथे लोक अपेक्षा करत नाहीत: प्रमाणीकरणासाठी वापरले जाणारे खाते, प्रमाणपत्राचा विषय, होम डिरेक्टरीखालील प्रोफाइल मार्ग, आणि बऱ्याचदा खरे नाव कोड करणारे मशीनचे नाव। खाते फील्ड संपादित करून होम मार्ग जसाच्या तसा ठेवणारा लॉग काहीच संपादित करत नाही।
| Field | What it identifies | Practical treatment |
|---|---|---|
| Account or username | A person, and often an employer | Replace consistently, keep the mapping |
| Certificate subject and CN | Device or user identity | Keep the structure, replace the value |
| Home directory path | A login name, sometimes a full name | Replace the segment, not the whole path |
| Machine or hostname | A person or a physical location | Replace with a stable pseudonym |
सपोर्ट अभियंत्याला फाइलभर एक सत्र पाहायचे असते तेव्हा पूर्णतेपेक्षा सुसंगती महत्त्वाची असते। मूल्ये हटवण्याऐवजी स्थिर लेबलांनी बदला, जेणेकरून एकाच वापरकर्त्याचे प्रत्येक दर्शन अजूनही तोच वापरकर्ता म्हणून वाचले जाईल। फील्ड पूर्णपणे हटवल्यास अभियंत्याला हवा असलेला धागा तुटतो आणि फाइल अधिक सुरक्षित होत नाही।
टाइमस्टॅम्पही एकूणच वैयक्तिक डेटा आहे। खाते कधी जोडले गेले ते एका महिन्याभरात घेतल्यास कामाचे तास आणि प्रवास वर्णन होतो। प्रश्नाला पूर्ण श्रेणी हवी नसेल, तर घटनेभोवतीच्या विंडोपर्यंत फाइल छाटा।
नेटवर्क ओळखणारी फील्ड
एंडपॉइंट पत्ते, अंतर्गत मार्ग आणि ढकललेले पर्याय खाजगी नेटवर्कचा आकार वर्णन करतात। हीच माहिती हल्लेखोराला हवी असते, आणि ती सहसा तिकिटाला हव्या असलेल्या पेक्षा खूप अधिक तपशिलात असते।
वापरात असलेले पत्ता कुटुंब शोधा, फक्त तुम्ही अपेक्षा केलेले नाही। दुहेरी स्टॅक क्लायंट IPv6 एंडपॉइंट आणि IPv6 मार्गांचा संच लॉग करू शकतो जो कोणी संपादित करण्याचा विचार केला नाही, कारण पुनरावलोकन फक्त ठिपकेदार चौकार शोधत होते।
grep -nEo '([0-9]{1,3}\.){3}[0-9]{1,3}' vpn-support.log | sort -u | head -n 40
grep -nEo '([0-9a-fA-F]{0,4}:){2,7}[0-9a-fA-F]{0,4}' vpn-support.log | sort -u | head -n 20
अद्वितीय यादी हाच मुद्दा आहे। फाइल किती वेगवेगळ्या पत्त्यांचा उल्लेख करते हे सांगते, आणि ते सहसा स्क्रोल करताना वाटते त्यापेक्षा खूप कमी असते। संपादनासाठी तपासणी यादी आणि सर्व समाविष्ट केल्याचे सिद्ध करण्याचा मार्गही देते। दहा पत्ते पाच मिनिटांचे काम आहे, आणि शंभर सांगतात की एक्सपोर्ट प्रश्नापेक्षा विस्तृत आहे।
अभियंत्याला हवे असल्यास टोपोलॉजी ठेवा। सबनेट संबंध राखून दुसरे आणि तिसरे ऑक्टेट बदलल्यास श्रेणी प्रकाशित न करता प्रश्नाचे उत्तर मिळते। तीच युक्ती IPv6 उपसर्गांसाठीही चालते। अभियंत्याला अपयशाचा आकार हवा असतो, आणि सुसंगत बदलीनंतरही आकार टिकतो।
गुपिते लेबलांमध्ये नाही, आकारांमध्ये लपतात
खाजगी कीजवळ “password” शब्दाची गरज नसते। ती मार्कर ओळींमधील ब्लॉक, लांब base64 स्ट्रिंग, किंवा इनलाइन कॉन्फिगरेशन डंप म्हणून दिसते। टोकन क्वेरी पॅरामीटर म्हणून दिसतात, आणि क्रेडेन्शियल्स क्लायंटने जसेच्या तसे लॉग केलेल्या URL मध्ये दिसतात।
grep -nE 'BEGIN [A-Z ]*PRIVATE KEY|password|passwd|token|secret|psk|auth-user-pass' vpn-support.log
grep -nE 'https?://[^ ]*:[^ ]*@' vpn-support.log
दुसरा नमुना लोक विसरतात तो आहे। स्कीम, वापरकर्ता, पासवर्ड, होस्ट अशा स्वरूपाचा URL पूर्ण क्रेडेन्शियल आहे, आणि प्रॉक्सी किंवा फीड इनलाइन प्रमाणीकरणासह कॉन्फिगर केलेले असताना क्लायंट असे URL लॉग करतात।
तुम्ही संपादित केले नाही हे सिद्ध करण्यासाठी मूळ फाइल कधीही पाठवू नका। ऑपरेटरने बदल न केलेल्या एक्सपोर्टवर आग्रह धरल्यास, तो कशासाठी हवा आहे विचारा, त्यांच्या पडताळलेल्या सपोर्ट चॅनेलमधून पाठवा, आणि नंतर तुमची स्थानिक प्रत हटवा। ती विनंती वैध आहे; सार्वजनिक पेस्ट नाही।
संपादित प्रत तयार करा आणि उतारा पाठवा
प्रतीवर काम करा, मूळ सुरक्षित जागी ठेवा, आणि हाताने नाही तर पुनरावृत्तीयोग्य कमांडने संपादित करा। पत्ता नमुन्यांवर एक फेरी त्यातील बहुतांश पकडते:
cp vpn-support.log vpn-support.original.log
sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/ADDR/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/USER@DOMAIN/g' \
vpn-support.original.log > vpn-support.redacted.log
grep -cE 'PRIVATE KEY|password|token' vpn-support.redacted.log
अंतिम संख्या शून्य असावी। नसेल, तर संपादन फेरीने एक आकार चुकवला आहे आणि काहीही पाठवण्यापूर्वी त्या ओळी पाहा। संपादित फाइल स्वतःच्या डोळ्यांनीही एकदा वाचा; स्क्रिप्ट नमुने पकडते, संदर्भ नाही।
अपयश अजूनही दाखवणारा सर्वात लहान उतारा पाठवा। त्रुटीभोवतीच्या दहा ओळी सहसा पुरतात, आणि त्या दोन मेगाबाइटच्या फाइलपेक्षा खूप सोप्या तपासता येतात। नंतर तुमची लेबल आणि खरी मूल्ये यांची जुळणी तुमच्या नियंत्रणातील जागी ठेवा, कारण पुढील प्रश्नाला ती लागेल।
OpenVPN चे लॉगिंग दस्तऐवज व्हर्बोसिटी स्तर काय रेकॉर्ड होते ते कसे बदलतात हे स्पष्ट करते, जे समस्येला फाइलचा किती भाग खरोखर हवा आहे हे ठरवण्यासाठी उपयुक्त संदर्भ आहे।