किन Port-Share सबै वेबसाइट आगन्तुकहरूलाई localhost जस्तो देखाउँछ

पहुँच लगको प्रत्येक लाइनले एउटै loopback ठेगाना देखाउँछ, जबकि पृष्ठ आफैं लोड हुन्छ र प्रमाणपत्र ठीकसँग प्रमाणित हुन्छ। अप्राप्यताको अर्थमा केही पनि बिग्रिएको छैन, र यही कारणले यो अवस्था महिनौंसम्म रहन्छ। बिग्रिएको कुरा सम्बद्धता हो: वेब ब्याकएन्डले जुन हपले जडान अगाडि पठायो त्यसको ठेगाना रेकर्ड गर्छ, र लगमा विश्वास गर्ने प्रत्येक पछिल्लो निर्णयले त्यही गलत उत्तर विरासतमा पायो।

तलका जाँचहरू केबलबाट भित्रतिर जान्छन्। तपाईंले देख्नुभएको मान व्याख्या गर्ने पहिलो जाँचमा रोक्नुहोस्, किनकि प्रत्येक पछिल्लो चरणले अघिल्ला पहिले नै सत्य छन् भन्ने मान्दछ। तीमध्ये कुनैले पनि फ्रन्ट-एन्ड कन्फिगरेसन अनुमान गर्न माग गर्दैन।

लग लाइन होइन, दुवै जडान पछ्याउनुहोस्

Port-Share एउटै TCP श्रोतामा दुई प्रोटोकल मल्टिप्लेक्स गर्छ। OpenVPN आउने जडानका पहिला बाइटहरू जाँच्छ, आफ्नै प्रोटोकल जस्तो देखिएमा त्यसलाई राख्छ, र बाँकी सबै दोस्रो गन्तव्यमा सुम्पन्छ। त्यो गन्तव्य सामान्यतया त्यही होस्टको वेब सर्भर हुन्छ, त्यसैले वेब सर्भरले स्वीकार गरेको सकेटको जोडीदार OpenVPN प्रक्रिया हुन्छ।

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

यही त्यो जाँच हो जसले बाँकी सबै निर्धारण गर्छ। यदि ब्याकएन्डको जोडीदार ब्राउजरको ठेगाना हो भने पोर्ट साझेदारी तपाईंको समस्या होइन, लग ढाँचा हो।

ट्रान्सपोर्ट फर्वार्डिङ हेडर इन्जेक्सन होइन

फर्वार्डरले बाइट सार्छ। यसले HTTP पार्स गर्दैन, त्यसैले कहिल्यै अनुरोधको रूपमा नपढेको अनुरोधमा हेडर घुसाउन सक्दैन, र नछोई पठाउने TLS स्ट्रिममा केही थप्न सक्दैन। प्रोक्सी हेडर अपेक्षा गर्ने मोड्युल कुनै पनि घटकले उत्पादन नगरेको हेडरको प्रतीक्षा गरिरहनेछ।

मूल ठेगाना दुई संयन्त्रले बोक्न सक्छन्, र दुवैलाई दुवै छेउमा सहमति चाहिन्छ। PROXY प्रोटोकलले जडानको सुरुमा सानो हेडर थप्छ, र ब्याकएन्ड त्यसको अपेक्षा गर्न कन्फिगर गरिएको हुनुपर्छ; अपेक्षा नगर्ने ब्याकएन्डले ती बाइटलाई अनुरोधको सुरुवात मानेर भ्रमित तरिकाले असफल हुन्छ। X-Forwarded-For जस्ता विश्वसनीय प्रोक्सी हेडरहरू तब काम गर्छन् जब HTTP बुझ्ने प्रोक्सीले ती सेट गर्छ र ब्याकएन्डलाई कुन जोडीदारले तिनको दाबी गर्न सक्छन् भनी बताइन्छ।

दुवैमध्ये कुनै पनि स्वचालित छैन, र कुनै पनि पूर्वनिर्धारित रूपमा सुरक्षित छैन। आउने कुनै पनि फर्वार्ड गरिएको हेडरमा विश्वास गर्ने ब्याकएन्डले क्लाइन्टलाई आफ्नै ठेगाना छान्न दिन्छ, जसले लगको अशुद्धिलाई पहुँच नियन्त्रण छल्ने बाटोमा परिणत गर्छ। उत्पादन मार्गमा कुनै पनि हेडरमा विश्वास गर्नुअघि स्टेजिङ होस्टमा एक पटक प्रदर्शन चलाउनुहोस्।

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

वैकल्पिक स्रोत-म्यापिङ निर्देशिका

पोर्ट साझेदारीमा वैकल्पिक निर्देशिका आर्गुमेन्ट छ जसले सुविधा लागू गरिएका प्लेटफर्महरूमा मूल स्रोत ठेगाना र फर्वार्डिङ जडानबीचको म्यापिङ रेकर्ड गर्छ। वेब पक्षले त्यो म्यापिङ हेर्ने अपेक्षा छ; यो हेडर होइन, र यो अनुरोधमा इन्जेक्ट गरिँदैन।

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

यो बाटो रोज्नुभयो भने यसलाई दुई आधाको एकीकरण मान्नुहोस्: फर्वार्डरले लेख्ने म्यापिङ र ब्याकएन्डले गर्ने खोज। दुवै प्रमाणित गर्नुहोस्, र निर्देशिकाले पुनःसुरुवात सहन्छ र व्यस्त श्रोतामा असीमित रूपमा बढ्दैन भनी पुष्टि गर्नुहोस्।

ठेगानाको जमानत कुन घटकले दिन्छ निर्णय गर्नुहोस्

कन्फिगरेसन बदल्नुअघि क्लाइन्ट ठेगाना दाबी गर्न अनुमति पाएको घटक र त्यसमा विश्वास गर्न अनुमति पाएका घटकहरूको नाम लिनुहोस्। एउटा लिखित उत्तरले तीन फरक तहले प्रत्येकले फरक स्रोतमा विश्वास गर्ने सामान्य विचलन रोक्छ।

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

जसले काम गर्दैन त्यो हो फर्वार्ड गरिएको loopback ठेगानालाई अनुरोध यही मेसिनमा उत्पन्न भयो भन्ने प्रमाण मान्नु। त्यो निष्कर्ष ठ्याक्कै उल्टो छ: ठेगाना छ किनकि स्थानीय घटकले जडान बनायो। यसरी लेखिएको नियमले श्रोतासम्म पुग्न सक्ने जो कोहीलाई प्रवेश दिन्छ।

नियमको परीक्षण गर्नुहोस्, पृष्ठको होइन

लोड हुने पृष्ठले फर्वार्डिङ मार्ग काम गर्छ भनी प्रमाणित गर्छ र सम्बद्धताबारे केही भन्दैन। ठेगानाको उपभोक्ताको परीक्षण गर्नुहोस्: पहुँच नियम, दर सीमा, अडिट प्रविष्टि, भौगोलिक खोज।

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

अधिकृत बाह्य अनुरोधलाई फ्रन्ट-एन्ड र ब्याकएन्ड दुवैको रेकर्डसँग तुलना गर्नुहोस्, र अस्वीकार गर्नुपर्ने नियमले अझै अस्वीकार गर्छ र स्वीकार गर्नुपर्ने नियमले अझै स्वीकार गर्छ भनी पुष्टि गर्नुहोस्। लग लाइन सही भए पनि नियमले अझै सबैलाई स्थानीय मानेर व्यवहार गर्छ भने नियमले तपाईंले सुधारेको फिल्डभन्दा फरक फिल्ड पढ्छ।

तैनाथी नोटमा सम्बद्धता श्रृंखला लेखेर टुङ्ग्याउनुहोस्: कुन श्रोता, कुन फर्वार्डर, कुन हेडर वा म्यापिङ, र कुन ब्याकएन्ड त्यसमा विश्वास गर्न कन्फिगर छ। अर्को पटक लग लाइन पढ्ने व्यक्तिलाई चारै चाहिन्छ, र त्यो नोट नहुनु नै त्यही टिकट एक वर्षपछि फेरि खुल्ने कारण हो। यसलाई च्याट थ्रेडमा होइन, कन्फिगरेसनको छेउमा राख्नुहोस्।