Bakit nabibigo ang ilang website kapag nakabukas lang ang VPN?

Ang pagkabigo ng isang site habang naglo-load ang lahat ng iba ay nagpapatunay na may dinadalang trapiko ang tunnel, at pinaliit nito ang problema nang higit sa inaasahan ng karamihan. Tatlong obserbasyon ang mag-aayos ng natitira: kung nakatanggap ka ng tugon ng HTTP, kung naresolba ang hostname sa isang address, at kung dumadaan ang maliliit na kahilingan habang nagsisistig ang malalaki. Ang paghula tungkol sa VPN bago ang mga sagot na iyon ay kadalasang naglilipat ng problema sa halip na alisin ito.

Pagsunod-sunurin ang mga obserbasyon, dahil ang site na tumugon ay hindi maaaring sabay na nabigo sa resolusyon. Kung wala talagang naglo-load, nasa maling sanga ka, at ang mga pagsusuri para sa konektado ngunit walang internet ang naaangkop.

Hayaang piliin ng mensahe ng error ang sanga

Ang pagtanggi, pagsubok laban sa bot, o pahina ng error ay nangangahulugang tumugon ang serbisyo, kaya nakarating ang mga packet sa isang aplikasyon at bumalik. Inililipat nito ang tanong sa patakaran ng pag-access ng site, na maaaring timbangin ang address ng labasan, ang account, o mga pattern ng kahilingan na hindi nito inilalathala. Ang pagkabigo sa resolusyon ng pangalan ay hindi kailanman nakarating sa site, at ang address ang unang dapat siyasatin. Ang timeout ay nasa pagitan ng dalawa: may ipinadala at walang nagpatunay nito.

Ang mga babala sa sertipiko ay kabilang sa ikaapat na sanga. Ibig sabihin, ang koneksyon ay tinugunan ng isang bagay na hindi maipatunay ng browser ang pagkakakilanlan, alinman sa isang proxy sa panig mo o isang tunay na hindi pagtutugma na hindi mo dapat i-click nang lagpas. Ituring itong tanong ng tiwala, hindi ng routing.

Ang site na tumutugon ay hindi nagpatunay ng sirang tunnel

Kapag ang tugon ay pahina ng pagharang, ihambing ang parehong pahina sa pamamagitan ng pangalawang labasan habang hindi binabago ang browser at ang makina. Kung ang resulta ay sumusunod sa address ng labasan, iba ang pagtrato ng site sa address na iyon, at walang configuration ng kliyente ang makakabago nito. Kung ang pagharang ay sumusunod sa browser mo, ang sanhi ay nasa isang extension, naka-save na proxy, o setting ng resolver. Dalawang pagtakbo ang naghihiwalay sa mga paliwanag na iyon nang mura.

Ang mga pagkabigo na sa browser lang nangyayari ay sapat na karaniwan upang subukan nang maaga. Ang pahinang naglo-load sa isang sinusuportahang browser at nabigo sa iba ay tumuturo sa kalagayan ng profile, blocker ng nilalaman, o naka-encrypt na DNS na naka-configure sa loob mismo ng browser. Ang gabay ng Chrome sa secure DNS ay nagpapakita kung nasaan ang setting na iyon, at ang pagbabago nito sa pamamagitan ng sinusuportahang kontrol ay mas mabuti kaysa i-reset ang device.

Kapag malalaking transfer lang ang nagsisistig, tingnan ang laki ng packet

Ang pahinang gumuhit ng header at pagkatapos ay nagsisistig ay may ibang lagda kaysa sa pahinang hindi kailanman nagsisimula. Ang maliliit na tugon ay maaaring dumaan habang ang buong laki ng payload ay itinatapon sa isang lugar na hindi makapagbibigay ng senyales sa nagpadala, at ganoon ang hitsura ng pagkabigo ng path MTU mula sa browser. Ihambing ang maliit na kahilingan at malaki sa parehong host bago magteorya tungkol sa pag-filter. Ang pagtuklas ng path MTU ay dapat matutunan ang pinakamaliit na laki ng link sa landas, at ito ay nakadepende sa feedback ng ICMP na regular na itinatapon ng mga na-filter na network.

Subukan ang hypothesis na iyon sa pamamagitan ng pag-scan ng laki sa halip na isang ping lang. Ang pagkabigong nagsisimula sa pare-parehong laki ng payload ay matibay na ebidensya, samantalang ang pagkabigong gumagalaw ay hindi.

Kumpirmahin ang pagwawasto sa kahilingang nabigo

Subukan muli ang orihinal na operasyon, hindi ang home page, dahil ang naka-cache na shell ay maaaring gumuhit habang ang tawag sa API sa likod ng pag-sign in ay nabigo pa rin. Hinihiwalay ng mga command sa ibaba ang resolusyon ng pangalan, maliit na kahilingan, at malaking kahilingan sa parehong host. Palitan ang hostname at path ng mga mula sa kahilingang talagang nasira.

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

Kung ang sagot ng dig ay naiiba sa ginamit ng browser, ang resolver ang variable, at ang sariling setting ng DNS ng browser ang lugar na titingnan. Kung ang maliit na kahilingan ay nagbabalik ng status habang ang malaki ay nagsisistig, gawin ang sanga ng laki ng packet. Kung pareho silang nag-time out, ang landas ng labasan at ang pagtrato ng site sa address na iyon ay bumalik sa mesa.

Panatilihin ang pagbabagong nagtagumpay sa orihinal na kahilingan at ibalik ang iba pa. Ang tambak ng sabay-sabay na pagbabago sa browser, resolver, at kliyente ay nag-iiwan sa iyong hindi masabi kung alin ang may mahalaga.