सॉकेट पीअर विरुद्ध फॉरवर्डेड हेडर: कोणत्या पत्त्यावर विश्वास ठेवायचा?

तुमच्या अनुप्रयोगावर येणारी विनंती दोन प्रकारचे पत्त्याचे पुरावे घेऊन येते: नेटवर्क कनेक्शन उघडणारा पीअर, आणि पूर्वीच्या क्लायंटचा पत्ता दावणारे HTTP फील्ड। ते वेगवेगळ्या प्रश्नांची उत्तरे देतात। सॉकेट पीअरचे निरीक्षण केले जाते, तर हेडरचा दावा ते लिहिणारा कोणीही करतो, आणि कोणीही लॉग किंवा प्रवेश नियमात दुसऱ्याला शांतपणे बदलू नये। खालील तुलना दोन्हींना वेगळे ठेवते आणि नंतर ती एकच रचना दाखवते ज्यात हेडर उपयुक्त होते।

काहीही तुलना करण्यापूर्वी मार्गाचे वर्णन करा:

Client -> approved reverse proxy -> application origin

त्या रचनेत मूळचा सॉकेट पीअर सामान्यतः प्रॉक्सी असतो, आणि फॉरवर्डिंग हेडर प्रॉक्सीचा क्लायंटबद्दलचा दावा वाहू शकतो। त्याचे मूल्य त्या प्रॉक्सीशी असलेल्या नियंत्रित संबंधातून येते, हेडरच्या नावातून नाही।

पत्त्याचे दोन प्रकारचे पुरावे

सॉकेट पीअर एका TCP कनेक्शनबद्दलची वस्तुस्थिती आहे: काहीतरी त्या पत्त्यावरून हँडशेक पूर्ण केले। तो तुम्हाला महत्त्वाचा असलेला माणूस, उपकरण किंवा खाते असणे आवश्यक नाही, कारण VPN किंवा Tor निर्गम वैधपणे तो स्रोत असू शकतो जो सेवा निरीक्षण करते। तरीही तो होस्टने स्वतः सत्यापित केलेला एकमेव पत्ता आहे, आणि त्याचे संपूर्ण मूल्य यातच आहे।

फॉरवर्डिंग फील्ड शृंखलेबद्दलचे मेटाडेटा आहे। X-Forwarded-For, X-Real-IP आणि प्रमाणित फील्ड Forwarded ते प्रतिध्वनी करणाऱ्या अंतिम टप्प्यापर्यंत पोहोचणारा कोणताही क्लायंट लिहू शकतो, त्यामुळे त्यांची विश्वासार्हता ते सेट करण्याची परवानगी कोणाला होती यावर पूर्णपणे अवलंबून आहे।

दोन्ही विनंती संदर्भात वेगळ्या नावांखाली ठेवा। पीअरला हेडरने अधिलिखित करणारा अनुप्रयोग नंतर विश्वासाची त्रुटी पुनर्रचित करण्याची क्षमता गमावतो, आणि तीच तुम्हाला त्याची गरज असलेली नेमकी क्षण असते।

हेडर कधीही कनेक्शनचा मार्ग बदलत नाही

फॉरवर्डिंग फील्डमध्ये पत्ता लिहिणे सर्व्हरवर येणाऱ्या TCP कनेक्शनचा स्रोत बदलत नाही, आणि मार्गावर कुठेही राउटिंग बदलत नाही। सामान्य VPN राउटिंग किंवा स्रोत NAT कोणत्याही HTTP हेडरशिवाय रहदारी पोहोचवते। त्याचप्रमाणे, ट्रान्झिट गेटवे TLS अंतिम टप्प्याची रचना न बदलता योग्यरित्या संरक्षित HTTPS देवघेव पुन्हा लिहीत नाही।

उलटी चूकदेखील तितकीच सामान्य आहे: HTTPS क्लायंटने दिलेले फॉरवर्डिंग हेडर खरे करत नाही। ते खोट्या दाव्याची वाहतूक खऱ्याच्या तितकीच चांगली संरक्षित करते।

जर सहकारी राउटिंग समस्या सोडवण्यासाठी हेडर बदलण्याचा सल्ला देत असेल, तर निदान आधीच चुकीचे गेले आहे। मार्ग दुरुस्त करा, किंवा हेडर लिहिणारे प्रॉक्सी कॉन्फिगरेशन दुरुस्त करा।

दावा करण्यास परवानगी असलेल्या प्रॉक्सीचे नाव द्या

दोन नियम फॉरवर्डिंग फील्ड उपयुक्त करतात, आणि दोन्ही कोड नाहीत, कॉन्फिगरेशन आहेत। किनार बाहेरून येणारे सर्व काही त्या फील्डांसाठीच्या स्वतःच्या दस्तऐवजीकृत वर्तनानुसार सामान्य करते किंवा टाकून देते। नंतर मूळ तुम्ही नाव दिलेल्या प्रॉक्सी मार्गातून बदली पत्ता घेते, दुसरीकडून नाही। दुसरा नियम क्लायंट इतर मार्गाने मूळपर्यंत पोहोचू शकत नाहीत तोपर्यंतच लागू राहतो, कारण थेट आणि प्रॉक्सीमार्फत येणाऱ्या दोन्ही विनंत्यांना उत्तर देणारे मूळ कोणाची सेवा करत आहे हे जाणत नाही।

NGINX चे खरे IP मॉड्यूल विभाजन स्पष्टपणे दाखवते। set_real_ip_from ज्यांच्या दाव्याची गणना होते त्या प्रेषकांची नावे देते, आणि real_ip_header कोणते फील्ड ते वाहते हे सांगते; पहिले विश्वास करते, दुसरे फक्त कुठे पाहावे हे सांगते।

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

केवळ हेडर-निवड सूचना स्वतःहून मूल्य कोणी पाठवले याबद्दल अजून काहीही स्थापित करत नाही।

वाहतूक सुरक्षिततेने तुम्ही विश्वास ठेवता त्या घटकांमधील संपूर्ण मार्ग चालावा। योग्यरित्या सामान्य करणारा किनारा ते मूल्य त्या क्षणी गमावतो जेव्हा खालील असुरक्षित टप्पा प्रवासादरम्यान दुसऱ्याला दावा संपादित करू देतो।

बहु-टप्पा शृंखलांचे जाणीवपूर्वक व्यवस्थापन करा

अनेक प्रॉक्सींना स्पष्ट शृंखला मॉडेल आवश्यक असते। कोणीतरी ब्लॉग पोस्टने तसे केले म्हणून स्वल्पविरामाने विभक्त सर्वात डावे किंवा उजवे मूल्य घेऊ नका; तुमच्या प्रॉक्सींपैकी कोणती जोडते, कोणती बदलते आणि कोणती येणारे फील्ड जपते हे शोधा। उदाहरणार्थ, NGINX आपल्या विश्वस्त संचाच्या विरुद्ध यादी मागे चालू शकते आणि आपल्या मालकीचा नसलेल्या पहिल्या पत्त्यावर थांबू शकते, आणि तो त्या उत्पादनाचा नियम आहे, प्रत्येक फ्रेमवर्क पाळतो असा कायदा नाही। तुमच्या प्रॉक्सीचे दस्तऐवज त्याच दोन प्रश्नांसह वाचा: ती कोणते मूल्य निवडते, आणि कोणत्या प्रेषकांवर विश्वास ठेवते?

शृंखला लिहून ठेवा: टप्प्यांचा क्रम, कोणता टप्पा फील्ड सेट करतो आणि कोणता टप्पा येणाऱ्या प्रती काढून टाकतो। नंतर ती नोंद केवळ तिकिटात नाही, प्रॉक्सी कॉन्फिगरेशनच्या शेजारी ठेवा। नंतर मंजूर सत्यापन प्रक्रियेतून बनावट हेडरसह विनंती पाठवून आणि मूळ ती दुर्लक्षित करते याची खात्री करून त्याची चाचणी करा।

जेव्हा तुम्ही टप्पा जोडता, तेव्हा ते दस्तऐवज पुन्हा पाहा। विश्वस्त प्रॉक्सीसमोर घातलेला नवीन लोड बॅलन्सर कोणीही अनुप्रयोग संपादित न करता कोणता पत्ता जिंकतो हे बदलू शकतो।

दोन्ही निरीक्षणे लॉगमध्ये ठेवा

जिथे निदान अधिकृत आहे, तिथे कनेक्शनचा पीअर आणि सामान्यीकृत क्लायंट पत्ता दोन वेगळी फील्ड म्हणून नोंदवा, आणि केवळ उद्दिष्टाला खरोखर आवश्यक असलेला फॉरवर्डिंग मेटाडेटा जोडा। नंतर दोन विनंत्यांनी तैनाती सिद्ध करा: दोन्ही मूल्ये समजूतदारपणे नोंदवायची असलेली प्रॉक्सीमार्फतची विनंती, आणि नाकारली पाहिजे अशी थेट मूळकडे केलेला प्रयत्न।

ही जोडी काय अर्थ दर्शवते ते लक्षात ठेवा। हेडर तुम्ही विश्वास ठेवण्यासाठी निवडलेल्या घटकाने पुरवलेला संदर्भ जोडते; पीअर हा तुमच्या होस्टने प्रत्यक्ष पाहिलेला एकमेव पत्ता राहतो। दोन्हीपैकी कोणतेही वैयक्तिक ओळखीचा पुरावा नाही, आणि कोणत्याही एकाला पुरावा मानणारी रचना कोणाबद्दलतरी चुकणार आहे।