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 उत्तरे तुलना करा.