Зошто некои страници не работат само кога е вклучен 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 поставка на браузерот е местото каде да се погледне. Ако малото барање враќа статус, додека големото заглавјува, обработете ја гранката за големината на пакетот. Ако двете истечат, излезната патека и односот на страницата кон таа адреса повторно се на маса.

Задржете ја промената поради која првобитното барање успеа и откажете го остатокот. Куп истовремени промени во браузерот, резолверот и клиентот ве оставаат неспособни да кажете која имала значење.

Поврзани статии