गेटवे कि अगाडि पठाइएको क्लाइन्ट? स्रोत ठेगाना पढ्ने

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

गन्तव्यले वास्तवमा के देख्छ

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 हेडर एप्लिकेसनले सेट गर्न सक्छ, र समयको समानताले साझा व्यक्ति नभई साझा पूर्वाधार प्रतिबिम्बित गर्न सक्छ। धेरै प्रयोगकर्ताले एउटै निकास साझा गर्न सक्छन्, र एउटा प्रयोगकर्ताले सत्रबीच मार्ग बदल्न सक्छ। सँगै जम्मा गर्दा, धेरै कमजोर सङ्केतले गेटवेको रेकर्डमा नजिकबाट हेर्ने औचित्य दिन सक्छ, तर थुप्रिएर ती बलियो प्रमाण बन्दैनन्।

ठेगानाले होइन, पहिचानले अधिकृत गर्नुहोस्

यदि गन्तव्यले गेटवे प्रशासनलाई टाढाका प्रयोगकर्ताको गतिविधिबाट अलग गर्नुपर्छ भने, ती भूमिकालाई छुट्टै प्रमाणित पहिचान र अनुमत कार्य दिनुहोस्। साझा सार्वजनिक स्रोत अझै नेटवर्क प्रतिबन्धका रूपमा काम गर्न सक्छ, तर यो प्रयोगकर्ता वा यन्त्रको प्रमाणीकरणको विकल्प होइन।

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

अवलोकनको मिति र यो उत्पादन गर्ने प्रणाली रेकर्ड गर्नुहोस्। आरोपण बिनाको लग अंश पछि बचाउन गाह्रो हुन्छ।