VPN підключено, але змішаний вміст усе ще блокується: що виправити
Відсортуйте заблокований URL за тим, хто його створив, виправте посилання або передайте його власнику хоста, а потім підтвердьте виправлення в консолі браузера.
Половина сторінки відмальовується, одна таблиця стилів показана сірою на панелі «Мережа», а клієнт VPN досі повідомляє про справний тунель. Усі три спостереження правильні одночасно, бо браузер оцінив запит, зроблений сторінкою, а тунель у цій оцінці не брав участі. Справу закриває рішення, а не налаштування: виправити посилання, ескалувати його власнику хоста або відмовитися від залежності. Кожен із цих варіантів має дешеву перевірку, а вибір неправильного коштує циклу підтримки.
Чому тунель не може покрити підресурс
Змішаний вміст починається з HTTPS-документа, який запитує підресурс звичайним HTTP. Кожен URL оцінюється за власною схемою, тому захист батьківського документа ніколи не поширюється на дочірній запит. Шифрування, додане нижче браузера, змінює те, що йде дротом, а не http://, який зажадала розмітка.
Сучасні браузери поділяють такі запити на дві групи й поводяться з ними по-різному. Скрипти, таблиці стилів, iframe та виклики через fetch, XMLHttpRequest або WebSocket відхиляються одразу, без попередньої спроби оновлення. Зображення, аудіо й відео переписуються на https:// і запитуються знову, а завантаження переривається, коли це безпечне отримання не вдається. URL підресурсу, хостом якого є гола IP-адреса, виключений з оновлення, тому HTTP-зображення на IP-хості залишається заблокованим, а не виправляється мовчки. Цей поділ, включно із зазначеним винятком на оновлюваному боці, описано в посібнику Mozilla про змішаний вміст. Chrome застосовує подібну відмову до небезпечних завантажень, розпочатих із безпечної сторінки, тому посилання на PDF може померти, поки сторінка навколо виглядає цілою.
Сірий рядок, отже, доводить, що перевірка працює, а не те, що тунель пропустив відкритий текст. Ставтеся до рядка як до знахідки, що вказує на одне посилання, а не на всю сторінку.
Визначте, кому належить небезпечне посилання
Відсортуйте проблемний URL за місцем, де він створюється, перш ніж щось змінювати. Ця відповідь вирішує, чи можете ви випустити виправлення сьогодні, чи його має випустити постачальник, чи залежність має залишити сторінку. Прочитайте його в стовпці Initiator на панелі «Мережа», бо розмітка на екрані часто збирається під час виконання.
| Звідки береться URL | Хто може його виправити | Перший крок |
|---|---|---|
| Жорстко заданий у шаблоні або частині, яку ви розгортаєте | Ви | Замініть його формою https:// і потім очистьте кеш |
| Впроваджений менеджером тегів або пакетом постачальника | Постачальник, з вашим тікетом | Надішліть точний URL, тип запиту й рядок консолі |
| Віддається лише на порту 80 без слухача TLS | Власник хоста | Попросіть TLS, поставте перед ним щось своє або відмовтеся від нього |
Коли хост уже відповідає на 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 змушує браузер переписувати URL підресурсів http, перш ніж вони покинуть сторінку, що ловить старі посилання, яких ви ще не знайшли. Переписаний запит усе одно не проходить, коли цільовий хост не віддає HTTPS, тому заголовок змінює лише те, який URL пробує браузер. HSTS діє на хост, тобто політика на вашому домені нічого не робить для стороннього CDN, який ніколи не надсилав заголовок. Після правки шаблону очистьте кеш сторінки й пошукайте старе ім'я хоста у відмальованому HTML, бо той самий URL може прийти й через частину, рядок перекладу або поле бази даних.
Відстежуйте й переспрямування, бо ланцюжок, що починається з https://, може потрапити на адресу http://, а браузер оцінює останній перехід. Форма -L другої команди вище виводить цей фактичний URL за вас. Якщо останній перехід — чистий http, посилання все одно хибне, хоча відредаговане вами посилання виглядало добре.
Підтвердьте сторінку консоллю та панеллю мережі
Перезавантажте з вимкненим кешем і пройдіть сценарій ще раз, включно з кнопками, що підвантажують вміст на вимогу. Перше завантаження сторінки приховує ліниві віджети, плитки карти й скрипти плеєра, які з'являються лише після кліку. У консолі не має бути записів про змішаний вміст, і кожен зачеплений рядок має показувати https. Зніміть консоль і рядок запиту до закриття тікета, бо цей стан важко відтворити після наступного розгортання.
Коли ресурс належить комусь іншому, надішліть чотири речі: точний URL, тип запиту, текст консолі й сторінку, де він з'являється. Приховайте ідентифікатори сеансу в усьому, що вставляєте в тікет. Звіт, який лише каже, що зображення зламані, не дає власнику нічого для пошуку.
Тунель далі робить свою роботу, поки виправлення лежить у посиланні, що створило запит. Після розгортання ще раз пошукайте ім'я хоста в шаблоні та пакеті постачальника й закривайте справу лише тоді, коли в консолі не залишиться жодного заблокованого запису про змішаний вміст.