VPN जोडलेले आहे पण संमिश्र सामग्री अजूनही अवरोधित आहे: काय दुरुस्त करावे

अर्धे पान रेंडर होते, एक स्टाइलशीट नेटवर्क पॅनेलमध्ये राखाडी राहते, आणि VPN क्लायंट अजूनही निरोगी टनेलची माहिती देतो। तीनही निरीक्षणे एकाच वेळी खरी आहेत, कारण ब्राउझरने पानाने केलेल्या विनंतीचा निवाडा केला आणि त्या निवाड्यात टनेलला काही मत नव्हते। प्रकरण बंद करणारी गोष्ट निर्णय आहे, सेटिंग नाही: संदर्भ दुरुस्त करा, तो होस्टच्या मालकापर्यंत न्या, किंवा अवलंबित्व सोडून द्या। यातील प्रत्येक पर्यायाला स्वस्त चाचणी आहे, आणि चुकीचा निवडणे एक सहाय्य चक्र खर्च करते।

टनेल उप-संसाधन का झाकू शकत नाही

संमिश्र सामग्रीची सुरुवात अशा HTTPS दस्तऐवजाने होते जो साध्या HTTP वर उप-संसाधन मागतो। प्रत्येक URL चे मूल्यांकन त्याच्या स्वतःच्या स्कीमवर होते, म्हणून मूळ दस्तऐवजाचे संरक्षण कधीही अपत्य विनंतीपर्यंत पोहोचत नाही। ब्राउझरच्या खाली जोडलेले एन्क्रिप्शन तारेवर जाणारे बदलते, ते http:// नाही जे मार्कअपने मागितले होते।

सध्याचे ब्राउझर या विनंत्या दोन गटांत विभागतात आणि वेगळ्या पद्धतीने हाताळतात। स्क्रिप्ट, स्टाइलशीट, iframe आणि fetch, XMLHttpRequest किंवा WebSocket द्वारे केलेले कॉल सरळ नाकारले जातात, आधी कोणताही अपग्रेड प्रयत्न न करता। प्रतिमा, ऑडिओ आणि व्हिडिओ https:// मध्ये पुन्हा लिहिले जातात आणि पुन्हा मागितले जातात, आणि ती सुरक्षित प्राप्ती अयशस्वी झाल्यास लोडिंग सोडले जाते। ज्या उप-संसाधनाचा होस्ट उघडा IP पत्ता आहे अशा URL ला अपग्रेडमधून सूट आहे, म्हणून 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, विनंती प्रकार, कन्सोल मजकूर आणि ते पान जिथे दिसते। तिकिटात चिकटवता त्या प्रत्येक गोष्टीतून सत्र ओळखणारे लपवा। फक्त प्रतिमा खराब आहेत असे सांगणारा अहवाल मालकाला शोधण्यासाठी काहीही देत नाही।

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