VPN जुड़ा है लेकिन मिश्रित सामग्री अब भी अवरुद्ध है: क्या ठीक करें

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

टनल किसी उप-संसाधन को क्यों नहीं ढक सकती

मिश्रित सामग्री की शुरुआत ऐसे HTTPS दस्तावेज़ से होती है जो सादे HTTP पर उप-संसाधन मांगता है। हर URL का मूल्यांकन उसकी अपनी स्कीम पर होता है, इसलिए मूल दस्तावेज़ की सुरक्षा कभी संतान अनुरोध तक नहीं फैलती। ब्राउज़र के नीचे जोड़ा गया एन्क्रिप्शन वह बदलता है जो तार पर जाता है, वह http:// नहीं जो मार्कअप ने मांगा था।

मौजूदा ब्राउज़र इन अनुरोधों को दो समूहों में बाँटते हैं और अलग तरह से संभालते हैं। स्क्रिप्ट, स्टाइलशीट, iframe और fetch, XMLHttpRequest या WebSocket से किए गए कॉल सीधे अस्वीकार कर दिए जाते हैं, बिना पहले कोई अपग्रेड प्रयास किए। तस्वीरें, ऑडियो और वीडियो https:// में फिर से लिखे जाते हैं और दोबारा माँगे जाते हैं, और जब वह सुरक्षित प्राप्ति विफल होती है तो लोडिंग छोड़ दी जाती है। ऐसे उप-संसाधन का URL जिसका होस्ट नंगा IP पता है, अपग्रेड से मुक्त रहता है, इसलिए IP होस्ट पर HTTP तस्वीर चुपचाप ठीक होने के बजाय अवरुद्ध रहती है। यह विभाजन, अपग्रेड हो सकने वाले पक्ष पर उस छूट सहित, यहाँ प्रलेखित है: Mozilla की मिश्रित सामग्री गाइड में। Chrome सुरक्षित पेज से शुरू होने वाले असुरक्षित डाउनलोड पर भी ऐसा ही अस्वीकार लागू करता है, इसीलिए PDF लिंक मर सकता है जबकि आसपास का पेज साबुत दिखता है।

इसलिए धूसर पंक्ति इस बात का प्रमाण है कि नियंत्रण काम कर रहा है, न कि इस बात का कि टनल ने सादा पाठ छोड़ा। पंक्ति को एक संदर्भ की ओर इशारा करने वाली खोज मानें, पूरे पेज की नहीं।

तय करें कि असुरक्षित संदर्भ किसका है

कुछ भी बदलने से पहले समस्या वाले URL को उस जगह के अनुसार छाँटें जहाँ वह बनता है। यही उत्तर तय करता है कि आप आज सुधार जारी कर सकते हैं, कोई विक्रेता एक जारी करेगा, या निर्भरता को पेज छोड़ना होगा। इसे नेटवर्क पैनल के Initiator स्तंभ में पढ़ें, क्योंकि स्क्रीन पर मार्कअप अक्सर रनटाइम में जोड़ा जाता है।

जब होस्ट पहले से 443 पर उत्तर दे रहा हो और केवल संदर्भ http कहे, तो सुधार स्थानीय है: संदर्भ बदलें, पेज का कैश साफ़ करें और पुष्टि करें कि पंक्ति https हो गई। ऐसा होस्ट जो केवल पोर्ट 80 पर सुनता है, संपादन से अनुरूप नहीं बनाया जा सकता, इसलिए संसाधन स्थानांतरित होता है, उसके आगे आपकी नियंत्रित चीज़ रख दी जाती है, या वह गायब हो जाता है। टैग प्रबंधक द्वारा डाला गया URL तब भी दिखता रहता है जब आपका अपना टेम्पलेट साफ़ हो, और वह मामला ऐसे टिकट का है जिसके साथ सटीक URL और कंसोल पंक्ति संलग्न हों। कर्मचारियों से असुरक्षित सामग्री की अनुमति देने को कहना इनमें से कोई विकल्प नहीं है, क्योंकि यह उस ब्राउज़र प्रोफ़ाइल द्वारा देखी जाने वाली हर साइट के लिए जाँच बंद कर देता है।

ब्राउज़र सेटिंग नहीं, संदर्भ ठीक करें

विफल हो रहे प्रवाह को नेटवर्क लॉग सुरक्षित रखते हुए फिर से लोड करें और पैनल को उस होस्ट पर फ़िल्टर करें जिस पर संदेह है। कंसोल URL और निर्देश का नाम लेता है, जो तय करता है कि अनुरोध अस्वीकार हुआ या अपग्रेड, टेम्पलेट छूने से पहले।

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

दो सहायक नियंत्रण जानने योग्य हैं और कोई भी सुधार का विकल्प नहीं है। Content-Security-Policy हेडर जिसमें upgrade-insecure-requests ब्राउज़र को पेज छोड़ने से पहले http उप-संसाधन URL फिर से लिखने पर मजबूर करता है, जो उन पुराने संदर्भों को पकड़ता है जो आपने अभी नहीं खोजे। फिर से लिखा गया अनुरोध तब भी विफल होता है जब लक्ष्य होस्ट HTTPS नहीं परोसता, इसलिए हेडर केवल यह बदलता है कि ब्राउज़र कौन सा URL आज़माता है। HSTS हर होस्ट पर लागू होता है, यानी आपके अपने डोमेन की नीति ऐसे तीसरे पक्ष के CDN के लिए कुछ नहीं करती जिसने कभी यह हेडर नहीं भेजा। टेम्पलेट बदलने के बाद पेज का कैश साफ़ करें और रेंडर किए गए HTML में पुराना होस्ट नाम खोजें, क्योंकि वही URL किसी आंशिक, अनुवाद स्ट्रिंग या डेटाबेस फ़ील्ड से भी आ सकता है।

रीडायरेक्ट भी ट्रैक करें, क्योंकि https:// से शुरू होने वाली श्रृंखला http:// स्थान पर उतर सकती है और ब्राउज़र अंतिम छलांग का निर्णय करता है। दूसरी कमांड की -L आकृति ऊपर वाला वह प्रभावी URL आपके लिए प्रिंट करती है। यदि अंतिम छलांग शुद्ध http है, तो संदर्भ अब भी गलत है चाहे आपका संपादित लिंक ठीक लगता हो।

पेज की पुष्टि कंसोल और नेटवर्क पैनल से करें

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

जब संसाधन किसी और का हो, चार चीज़ें भेजें: सटीक URL, अनुरोध प्रकार, कंसोल पाठ और वह पेज जहाँ यह दिखता है। टिकट में चिपकाए किसी भी चीज़ से सत्र पहचानकर्ता छिपाएँ। वह रिपोर्ट जो केवल कहती है कि तस्वीरें खराब हैं, स्वामी को खोजने के लिए कुछ नहीं देती।

टनल अपना काम जारी रखती है जबकि सुधार उस संदर्भ में है जिसने अनुरोध बनाया। तैनाती के बाद टेम्पलेट और विक्रेता बंडल में होस्ट नाम एक बार फिर खोजें, और मामला केवल तब बंद करें जब कंसोल में कोई अवरुद्ध मिश्रित सामग्री प्रविष्टि न बचे।