Чому деякі сайти не відкриваються лише з увімкненим VPN?

Якщо не працює один сайт, а решта завантажується, це швидко звужує несправність. Прочитайте помилку, перевірте розв'язання імен, а потім перегляньте розмір пакета, перш ніж чіпати клієнт.

Те, що один сайт не працює, а все інше завантажується, доводить, що тунель передає трафік, і це звужує проблему сильніше, ніж більшість очікує. Три спостереження впорядковують решту: чи отримали ви взагалі відповідь HTTP, чи розв'язалося ім'я хоста в адресу і чи проходять малі запити, поки великі зависають. Здогадки про VPN до отримання цих відповідей зазвичай переносять несправність, а не усувають її.

Розбирайте спостереження по порядку, бо сайт, який відповів, не міг одночасно не розв'язатися. Якщо взагалі нічого не завантажується, ви в іншій гілці, і діють перевірки для підключено, але без інтернету.

Нехай повідомлення про помилку вибере гілку

Відмова, антибот-перевірка або сторінка помилки означають, що служба відповіла, тобто пакети дійшли до застосунку й повернулися. Це переносить питання до політики доступу сайту, яка може враховувати адресу виходу, обліковий запис або непубліковані шаблони запитів. Збій розв'язання імен взагалі не дійшов до сайту, і адреса — перше, що треба перевірити. Тайм-аут лежить між ними: щось було надіслано, і ніщо це не підтвердило.

Попередження про сертифікати належать до четвертої гілки. Вони означають, що з'єднання обслужило щось, чию особу браузер не зміг перевірити: або проксі на вашому боці, або справжня невідповідність, крізь яку не варто клікати. Вважайте це питанням довіри, а не маршрутизації.

Сайт, який відповідає, ще не довів поломку тунелю

Коли відповідь — сторінка блокування, порівняйте ту саму сторінку через другий вихід, не змінюючи браузер і машину. Якщо результат іде за адресою виходу, сайт обробляє цю адресу інакше, і жодне налаштування клієнта цього не змінить. Якщо блокування йде за вашим браузером, причина в розширенні, збереженому проксі або налаштуванні розв'язувача. Два прогони дешево розділяють ці пояснення.

Збої лише в браузері досить часті, щоб перевіряти їх рано. Сторінка, яка завантажується в одному підтримуваному браузері й збоїть в іншому, вказує на стан профілю, блокувальник вмісту або зашифрований DNS, налаштований усередині самого браузера. Настанови Chrome щодо безпечного DNS показують, де міститься це налаштування, і змінити його через підтримуваний елемент керування краще, ніж скидати пристрій.

Коли зависають лише великі передачі, дивіться на розмір пакета

Сторінка, яка промальовує заголовок і потім зависає, має інший підпис, ніж сторінка, яка ніколи не починається. Малі відповіді можуть проходити, поки повнорозмірне корисне навантаження десь відкидається, що не може сигналізувати відправнику, і саме так виглядає збій MTU шляху з браузера. Порівняйте крихітний запит і великий до того самого хоста, перш ніж теоретизувати про фільтрацію. Виявлення MTU шляху має вивчати найменший розмір ланки на шляху, і воно залежить від відгуків ICMP, які фільтрувальні мережі регулярно відкидають.

Перевірте цю гіпотезу перебором розмірів, а не одним пінгом. Збій, що починається за сталого розміру корисного навантаження, — сильний доказ, а збій, що зміщується, — ні.

Підтвердьте виправлення на запиті, який збоїв

Повторіть початкову операцію, а не головну сторінку, бо кешована оболонка може промальовуватися, поки виклик API за входом досі збоїть. Команди нижче розділяють розв'язання імен, малий запит і великий до того самого хоста. Підставте ім'я хоста й шлях із запиту, який справді зламався.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Якщо відповідь dig відрізняється від тієї, що використав браузер, змінною є розв'язувач, і власне налаштування DNS браузера — місце, куди дивитися. Якщо малий запит повертає статус, поки великий зависає, пропрацюйте гілку розміру пакета. Якщо обидва вичерпують час, шлях виходу й ставлення сайту до цієї адреси знову на столі.

Збережіть зміну, завдяки якій початковий запит пройшов, і скасуйте решту. Купа одночасних правок у браузері, розв'язувачі й клієнті не дасть сказати, яка з них мала значення.

Схожі статті