सकेट पियर वा फर्वार्डेड हेडर: कुन ठेगानामा भरोसा गर्ने?

तपाईंको अनुप्रयोगमा आउने अनुरोधले दुई प्रकारका ठेगाना-प्रमाण बोक्छ: नेटवर्क जडान खोल्ने पियर, र अघिल्लो ग्राहकको ठेगाना दाबी गर्ने 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 ले आफ्नो विश्वस्त समूहविरुद्ध सूची पछाडि हिँड्न सक्छ र आफ्नो स्वामित्वमा नभएको पहिलो ठेगानामा रोकिन सक्छ, र त्यो त्यो उत्पादनको नियम हो, हरेक फ्रेमवर्कले पालना गर्ने कानुन होइन। आफ्नै प्रोक्सीको कागजात तीही दुई प्रश्नसहित पढ्नुहोस्: यसले कुन मान छान्छ, र कुन प्रेषकलाई विश्वास गर्छ?

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

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

दुवै अवलोकन लगमा राख्नुहोस्

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

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