गेटवे या फ़ॉरवर्ड किया गया क्लाइंट? स्रोत पता पढ़ना

वेब सर्वर एक पता लॉग करता है, और सब मानते हैं कि वह गेटवे की अपनी प्रक्रिया का है। हो सकता है वह ऐसे फ़ॉरवर्ड किए गए क्लाइंट का हो जिसका निजी पता अनुवाद के चरण में गायब हो गया। गंतव्य केवल दिखाई देने वाला नेटवर्क स्रोत देखता है, इससे अधिक कुछ नहीं। यह सीमा का कथन है, यह दावा नहीं कि मूल कभी स्थापित नहीं किया जा सकता।

गंतव्य वास्तव में क्या देखता है

10.20.0.7 पर एक क्लाइंट, बाहरी पता 198.51.100.10 वाला गेटवे, और इंटरनेट पर एक गंतव्य लें। यदि गेटवे क्लाइंट के स्रोत का अनुवाद करता है, तो गंतव्य का सॉकेट 198.51.100.10 दर्ज करता है। निजी पता पैकेट से चला जाता है, और गंतव्य उसे उस हेडर से वापस नहीं पढ़ सकता। ये संख्याएँ उदाहरण हैं, आपके नेटवर्क से लिया गया कैप्चर नहीं।

अवलोकन फिर भी उपयोगी है: यह उस नेटवर्क स्रोत की पहचान करता है जिसे गंतव्य को अनुमति देनी है या ब्लॉक करना है। यह बस उसके पीछे के व्यक्ति या प्रक्रिया की पहचान नहीं करता। गंतव्य के संचालक के लिए, यह अंतर तय करता है कि ब्लॉक नेटवर्क-निर्णय है या खाता-निर्णय।

अनुवाद स्थिति गंतव्य को दिखाई नहीं देती

गेटवे अनुवादित कनेक्शन और मूल क्लाइंट के बीच मैपिंग रखता है, और गंतव्य के पास ठीक यही स्थिति नहीं है। पारंपरिक NAT विवरण अनुवाद रिकॉर्ड को बाद में दिखाई देने वाले हेडर से अलग करता है। एक पक्ष पढ़ने से दूसरा नहीं मिलता।

अलग-अलग डिज़ाइन अलग-अलग साक्ष्य देते हैं। संरक्षित स्रोत पतों के साथ रूट किया गया ट्रैफ़िक क्लाइंट का असली पता दिखाता है, जबकि एप्लिकेशन प्रॉक्सी कनेक्शन समाप्त करके नया बनाता है। संरक्षित-स्रोत मार्ग के लिए यह भी आवश्यक है कि क्लाइंट का पता गंतव्य से वापस रूट करने योग्य हो, जो हर परिनियोजन प्रदान नहीं करता। लॉग की पंक्ति की व्याख्या करने से पहले पूछें कि कौन-सा डिज़ाइन तैनात है।

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL और फ़िंगरप्रिंट सुराग हैं, प्रमाण नहीं

IPv4 में TTL प्रेषक द्वारा चुने गए प्रारंभिक मान और पैकेट द्वारा तय किए गए हॉप्स की संख्या पर निर्भर करता है। दोनों तथ्यों के बिना, कोई मान यह सिद्ध नहीं कर सकता कि VPN हॉप हुआ। ज्ञात अतिरिक्त रूट किया गया हॉप भी LAN राउटर, टनल पथ या किसी अन्य फ़ॉरवर्डिंग व्यवस्था में अंतर नहीं कर पाता। TTL अंतर को प्रश्न मानें, निष्कर्ष नहीं।

अन्य संकेत भी वैसे ही व्यवहार करते हैं। User-Agent हेडर एप्लिकेशन द्वारा सेट किया जा सकता है, और समय की समानता साझा व्यक्ति के बजाय साझा अवसंरचना को दर्शा सकती है। कई उपयोगकर्ता एक निकास साझा कर सकते हैं, और एक उपयोगकर्ता सत्रों के बीच मार्ग बदल सकता है। एक साथ मिलाकर, कई कमज़ोर संकेत गेटवे के रिकॉर्ड पर नज़दीकी नज़र का औचित्य दे सकते हैं, लेकिन जमा होकर वे मज़बूत साक्ष्य नहीं बनते।

पते से नहीं, पहचान से अधिकृत करें

यदि गंतव्य को गेटवे प्रशासन को दूरस्थ उपयोगकर्ता गतिविधि से अलग करना है, तो उन भूमिकाओं को अलग प्रमाणित पहचान और अनुमत संचालन दें। साझा सार्वजनिक स्रोत अभी भी नेटवर्क प्रतिबंध के रूप में काम कर सकता है, परंतु वह उपयोगकर्ता या डिवाइस के प्रमाणीकरण का विकल्प नहीं है।

साक्ष्य लेबल सहित रखें: देखा गया स्रोत, प्रमाणित खाता, समय और विचाराधीन अनुमान। «यहाँ कोई आंतरिक स्रोत दिखाई नहीं देता» का अनुवाद «कहीं भी कोई आरोपण संभव नहीं» के रूप में न करें। लेबल तब मायने रखता है जब महीनों बाद कोई ऐसा व्यक्ति रिकॉर्ड पढ़ता है जो जाँच का हिस्सा नहीं था।

अवलोकन की तारीख और वह सिस्टम जिसने इसे उत्पन्न किया, दर्ज करें। आरोपण के बिना लॉग अंश का बाद में बचाव करना कठिन है।