गेटवे की फॉरवर्ड केलेला क्लायंट? स्रोत पत्ता वाचणे

वेब सर्व्हर एक पत्ता नोंदवतो, आणि तो गेटवेच्याच प्रक्रियेचा आहे असे सर्वांना वाटते. तो अशा फॉरवर्ड केलेल्या क्लायंटचा असू शकतो ज्याचा खाजगी पत्ता अनुवादाच्या टप्प्यात गायब झाला. गंतव्य फक्त दिसणारा नेटवर्क स्रोत पाहते, त्यापेक्षा जास्त काही नाही. हे सीमेचे विधान आहे, मूळ कधीही स्थापित करता येणार नाही असा दावा नाही.

गंतव्य प्रत्यक्षात काय पाहते

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 हेडर अनुप्रयोग सेट करू शकतो, आणि वेळेची समानता सामायिक व्यक्तीऐवजी सामायिक पायाभूत सुविधा दर्शवू शकते. अनेक वापरकर्ते एकच निर्गम सामायिक करू शकतात, आणि एक वापरकर्ता सत्रांदरम्यान मार्ग बदलू शकतो. एकत्र गोळा केल्यास, अनेक कमकुवत संकेत गेटवेच्या नोंदींकडे जवळून पाहण्याचे समर्थन करू शकतात, पण साचून ते मजबूत पुरावे बनत नाहीत.

पत्त्याने नाही, ओळखीने अधिकृत करा

गंतव्याला गेटवे प्रशासन दूरस्थ वापरकर्त्याच्या क्रियाकलापांपासून वेगळे करायचे असल्यास, त्या भूमिकांना स्वतंत्र प्रमाणित ओळखी आणि अनुमत क्रिया द्या. सामायिक सार्वजनिक स्रोत अजूनही नेटवर्क मर्यादा म्हणून काम करू शकतो, पण तो वापरकर्ता किंवा उपकरणाच्या प्रमाणीकरणाचा पर्याय नाही.

पुरावे लेबलासह ठेवा: निरीक्षित स्रोत, प्रमाणित खाते, वेळ आणि विचाराधीन अनुमान. «येथे कोणताही अंतर्गत स्रोत दिसत नाही» याचे «कुठेही आरोपण शक्य नाही» असे भाषांतर करू नका. महिन्यांनंतर तपासाचा भाग नसलेला एखादा व्यक्ती नोंद वाचतो तेव्हा लेबल महत्त्वाचे असते.

निरीक्षणाची तारीख आणि ते तयार करणारी प्रणाली नोंदवा. आरोपणाशिवाय लॉगचा तुकडा नंतर सांभाळणे कठीण आहे.