VPN ബന്ധിപ്പിച്ചു എന്നാൽ മിശ്രിത ഉള്ളടക്കം ഇപ്പോഴും തടഞ്ഞിരിക്കുന്നു: എന്ത് ശരിയാക്കണം

പേജിന്റെ പകുതി റെൻഡർ ചെയ്യുന്നു, ഒരു സ്റ്റൈൽഷീറ്റ് നെറ്റ്വർക്ക് പാനലിൽ ചാരനിറത്തിൽ നിൽക്കുന്നു, VPN ക്ലയന്റ് ഇപ്പോഴും ആരോഗ്യകരമായ ടണൽ റിപ്പോർട്ട് ചെയ്യുന്നു. മൂന്ന് നിരീക്ഷണങ്ങളും ഒരേസമയം ശരിയാണ്, കാരണം ബ്രൗസർ പേജ് ഉണ്ടാക്കിയ അഭ്യർത്ഥന വിധിച്ചു, ആ വിധിയിൽ ടണലിന് ഒരു വോട്ടുമില്ലായിരുന്നു. കേസ് അവസാനിപ്പിക്കുന്നത് ഒരു തീരുമാനമാണ്, ഒരു ക്രമീകരണമല്ല: റഫറൻസ് ശരിയാക്കുക, അത് ഹോസ്റ്റിന്റെ ഉടമയിലേക്ക് ഉയർത്തുക, അല്ലെങ്കിൽ ആശ്രിതത്വം ഉപേക്ഷിക്കുക. ഈ ഓരോ ഓപ്ഷനും വിലകുറഞ്ഞ പരിശോധനയുണ്ട്, തെറ്റായത് തിരഞ്ഞെടുക്കുന്നത് ഒരു പിന്തുണാ ചക്രം ചെലവഴിക്കുന്നു.

ടണലിന് ഒരു ഉപ-വിഭവം എന്തുകൊണ്ട് മൂടാൻ കഴിയില്ല

മിശ്രിത ഉള്ളടക്കം ആരംഭിക്കുന്നത് സാധാരണ HTTP-യിലൂടെ ഉപ-വിഭവം ആവശ്യപ്പെടുന്ന ഒരു HTTPS രേഖയിൽ നിന്ന്. ഓരോ 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, അഭ്യർത്ഥന തരം, കൺസോൾ ടെക്സ്റ്റ്, അത് പ്രത്യക്ഷപ്പെടുന്ന പേജ്. ടിക്കറ്റിൽ ഒട്ടിക്കുന്ന എല്ലാത്തിൽ നിന്നും സെഷൻ ഐഡന്റിഫയറുകൾ മറയ്ക്കുക. ചിത്രങ്ങൾ കേടായി എന്ന് മാത്രം പറയുന്ന റിപ്പോർട്ട് ഉടമയ്ക്ക് തിരയാൻ ഒന്നും നൽകുന്നില്ല.

തിരുത്തൽ അഭ്യർത്ഥന സൃഷ്ടിച്ച റഫറൻസിൽ ആയിരിക്കുമ്പോൾ ടണൽ തന്റെ ജോലി തുടരുന്നു. വിന്യാസത്തിന് ശേഷം ടെംപ്ലേറ്റിലും വിതരണക്കാരന്റെ ബണ്ടിലിലും ഹോസ്റ്റ് നാമം ഒരിക്കൽ കൂടി തിരയുക, കൺസോളിൽ തടഞ്ഞ മിശ്രിത ഉള്ളടക്ക എൻട്രി ഒന്നും ബാക്കിയില്ലെങ്കിൽ മാത്രം കേസ് അടയ്ക്കുക.