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

अधिकृत बाह्य विनंतीची फ्रंट-एंड आणि बॅकएंड दोन्ही नोंदींशी तुलना करा, आणि नाकारायला हवा तो नियम अजूनही नाकारतो आणि स्वीकारायला हवा तो अजूनही स्वीकारतो याची खात्री करा. लॉग ओळ बरोबर असूनही नियम सर्वांना स्थानिक मानून वागत असेल, तर नियम आपण दुरुस्त केलेल्या फील्डपेक्षा वेगळे फील्ड वाचत आहे.

तैनाती नोट्समध्ये श्रेयाची साखळी लिहून पूर्ण करा: कोणता श्रोता, कोणता फॉरवर्डर, कोणता हेडर किंवा मॅपिंग, आणि कोणता बॅकएंड त्यावर विश्वास ठेवण्यासाठी कॉन्फिगर आहे. पुढील ज्या व्यक्तीला लॉग ओळ वाचायची असेल तिला चारही लागतील, आणि ती नोंद नसणे हेच त्याच तिकिटाचे वर्षानंतर पुन्हा उघडण्याचे कारण आहे. ती चॅट थ्रेडमध्ये नाही, कॉन्फिगरेशनशेजारी ठेवा.