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 उत्तर तुलना गर्नुहोस्.