VPN क्लाइंट के लिए NGINX कौन-सा स्रोत पता लॉग करेगा?
एक ही होस्ट पर OpenVPN के साथ NGINX क्या देखता है, यह तय करें: आंतरिक टनल पता, सार्वजनिक निकास पता, या अग्रेषित पीयर — तय हुए मार्ग के अनुसार।
एक ही होस्ट पर NGINX और OpenVPN की सेटिंग में तीन क्लाइंट पते दिखते हैं, हर उस मार्ग के लिए एक जो कोई अनुरोध ले सकता है. टनल पते पर पहुँचने वाला ब्राउज़र, सार्वजनिक पते पर पहुँचने वाला ब्राउज़र और गेटवे के इंटरनेट मार्ग से बाहर जाने वाला प्रोग्राम, सुनने वाले सॉकेट पर सब अलग दिखते हैं। लॉग पंक्ति की व्याख्या करने से पहले तय करें कि आप कौन-सा मार्ग देख रहे हैं। यह निर्णय क्लाइंट द्वारा इस्तेमाल किए गए गंतव्य पर, बाहरी VPN एंडपॉइंट के लिए उसके पास मौजूद अपवाद पर, और इस पर निर्भर करता है कि मार्ग में कुछ पैकेट का अनुवाद करता है या नहीं।
गंतव्य से तय करें, यह देखकर नहीं कि उपयोगकर्ता कौन है
उस पते से शुरू करें जिस पर अनुरोध भेजा गया था, क्योंकि वही पता मार्ग चुनता है। होस्ट के टनल पते पर अनुरोध टनल इंटरफ़ेस पर क्लाइंट के आंतरिक पते को स्रोत बनाकर आता है। होस्ट के सार्वजनिक पते पर अनुरोध आम तौर पर इंटरनेट की ओर के इंटरफ़ेस पर क्लाइंट के सार्वजनिक पते के साथ आता है, तब भी जब उसी लैपटॉप पर उस समय टनल स्थापित हो। इसलिए VPN पूल में सदस्यता पैकेट के मार्ग का गुण है, उपयोगकर्ता का पीछा करने वाला गुण नहीं।
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
जब लॉग में ऐसे पते के साथ कोई VPN उपयोगकर्ता दिखे जिसका टनल से कोई संबंध न हो, तब पहले यही तीसरी पंक्ति जाँचने योग्य है। यह भी बताता है कि एक ही प्रोफ़ाइल वाले दो उपयोगकर्ता अलग-अलग प्रविष्टियाँ क्यों बना सकते हैं: उनके अपने एक्सेस नेटवर्क अलग हैं, और टनल के अंदर कुछ भी उस पर दोबारा नहीं लिखता।
बाहरी एंडपॉइंट दूसरा सार्वजनिक मार्ग क्यों बनाता है
क्लाइंट को टनल स्थापित करने के लिए गेटवे के सार्वजनिक पते तक पहुँचना होता है, इसलिए उस पते तक का मार्ग टनल के बाहर मौजूद होना चाहिए। जब क्लाइंट सारा ट्रैफ़िक अंदर की ओर मोड़ देता है, तो समझदार कार्यान्वयन सर्वर के सार्वजनिक पते के लिए स्पष्ट होस्ट रूट रखता है ताकि ऐसी टनल से बचा जा सके जो स्वयं पर निर्भर हो। वह अपवाद सेवाओं के मामले में चयनात्मक नहीं है, इसलिए उसी सार्वजनिक पते पर जाने वाला हर अनुरोध उसका पालन करता है, गेटवे पर होस्ट की गई साइट के लिए ब्राउज़र अनुरोध भी शामिल है।
इस क्षेत्र की अधिकांश भ्रामक रिपोर्टों के पीछे यही तंत्र है, और यह सर्वर के बजाय क्लाइंट कार्यान्वयन पर निर्भर करता है। इसलिए एक जैसी प्रोफ़ाइल वाले दो क्लाइंट अलग व्यवहार कर सकते हैं। लॉग »ठीक करने« के लिए अपवाद हटाने से टनल भी साथ गिर जाता है, इसलिए इसे रखें और इसके चारों ओर डिज़ाइन करें।
सॉकेट, तालिका और लॉग प्रारूप को साथ पढ़ें
तीन अवलोकन तय करते हैं कि आप कौन-सा मार्ग देख रहे हैं: सॉकेट कहाँ सुनता है, कौन-सा इंटरफ़ेस गंतव्य का उत्तर देता है, और लॉग प्रारूप वास्तव में क्या दर्ज करता है। यदि श्रोता केवल टनल पते से बंधा है, तो सार्वजनिक अनुरोध वहाँ पहुँच ही नहीं सकता, जो तुरंत दो पंक्तियाँ हटा देता है। यदि क्लाइंट के लिए खोज टनल डिवाइस लौटाती है, तो अनुरोध आंतरिक स्रोत के साथ आया है और लॉग को वह दिखाना चाहिए।
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44फिर पंक्ति नहीं, प्रारूप पढ़ें। अग्रेषित हेडर से भरा फ़ील्ड दावा दर्ज करता है, सॉकेट पीयर नहीं, और दावा केवल तब मायने रखता है जब तात्कालिक पीयर एक विश्वसनीय प्रॉक्सी हो। दोनों मान लॉग में लिखने से बाद के विवाद तय हो जाते हैं, क्योंकि तात्कालिक पीयर और प्रतिस्थापित पता अलग तथ्य हैं और उनमें से केवल एक नेटवर्क से आया है।
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confअपना इच्छित प्रवेश बिंदु चुनें और DNS को सहमत कराएँ
यदि साइट केवल टनल से होनी है, तो उसे ऐसा नाम दें जो VPN क्लाइंट के लिए टनल पते पर हल हो और सुनने वाले सॉकेट पर नीति लागू करें। आंतरिक नाम के लिए 10.24.0.1 लौटाने वाला विभाजित DNS उत्तर नाम-समाधान के विवरण के वेश में मार्ग का निर्णय है। यदि साइट को सार्वजनिक भी होना है, तो दो नाम या दो पोर्ट रखें और लॉग को बताने दें कि किसने अनुरोध की सेवा की।
अनुमति के नियम वही तर्क अपनाते हैं। टनल पूल को अनुमति देना सार्वजनिक अनुरोध को अधिकृत नहीं करता और इंटरनेट से आए कनेक्शन पर आंतरिक पता नहीं भरेगा। दोनों प्रवेश बिंदुओं को एक नाम के नीचे मिलाने से दर्ज स्रोत डिज़ाइन विकल्प के बजाय क्लाइंट मार्ग का दुष्प्रभाव बन जाता है।
मार्ग सत्यापित करें, फिर नीति
गेटवे पर कैप्चर और अपने नियंत्रित अनुरोध से मार्ग की पुष्टि करें। टनल डिवाइस पर कैप्चर और सार्वजनिक इंटरफ़ेस पर एक, दिखाते हैं कि किसने बाइट ढोए, और पैकेटों का क्रम बताता है कि उनके बीच अनुवाद हुआ या नहीं।
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5फिर दोनों दिशाओं में पहुँच सत्यापित करें: इच्छित नाम वाला प्रवेश बिंदु इच्छित क्लाइंट के लिए काम करता है, और अस्वीकृत सार्वजनिक मार्ग केवल धीमा होने के बजाय अस्वीकार होता है। एक सामान्य IP-प्रतिध्वनि साइट गेटवे के इंटरनेट निकास के बारे में कुछ सिद्ध करती है और उसी होस्ट पर इस साइट के बारे में कुछ नहीं। जब कोई पृष्ठ और WebSocket सहमत न हों, तो सर्वर कॉन्फ़िगरेशन छूने से पहले उनके URL, पता परिवार और DNS उत्तरों की तुलना करें।