Niyə bəzi saytlar yalnız VPN açıq olanda açılmır?

Bir saytın işləmədiyi halda qalan hər şeyin yüklənməsi tunelin trafik daşıdığını sübut edir və bu, problemi çoxlarının gözlədiyindən daha çox daraldır. Üç müşahidə qalanı sıralayır: ümumiyyətlə HTTP cavabı aldınızmı, host adı ünvana həll olundumu və kiçik sorğular keçərkən böyüklər ilişib qalırmı. Bu cavablar olmadan VPN haqqında təxmin yürütmək adətən nasazlığı aradan qaldırmaq əvəzinə yerini dəyişir.

Müşahidələri sıra ilə işləyin, çünki cavab verən sayt eyni zamanda həlldə də uğursuz ola bilməzdi. Əgər heç nə yüklənmirsə, səhv budaqdasınız və qoşulub, lakin internetsiz hal üçün yoxlamalar qüvvədədir.

Qoy xəta mesajı budağı seçsin

İmtina, antibot çağırışı və ya xəta səhifəsi xidmətin cavab verdiyini bildirir, yəni paketlər bir tətbiqə çatıb geri qayıtdı. Bu, sualı saytın giriş siyasətinə keçirir, hansı ki çıxış ünvanını, hesabı və ya dərc etmədiyi sorğu nümunələrini çəkə bilər. Ad həllindəki nasazlıq sayta heç çatmadı, və ünvan yoxlanmalı ilk şeydir. Vaxt aşımı ikisinin arasındadır: nəsə göndərildi və heç nə onu təsdiqləmədi.

Sertifikat xəbərdarlıqları dördüncü budağa aiddir. Onlar bağlantıya brauzerin kimliyini yoxlaya bilmədiyi bir şeyin cavab verdiyini bildirir: ya sizin tərəfinizdə proxy, ya da üzərinə klikləməməli olduğunuz əsl uyğunsuzluq. Buna marşrutlaşdırma deyil, etibar məsələsi kimi yanaşın.

Cavab verən sayt qırıq tuneli sübut etməyib

Cavab bloklama səhifəsidirsə, brauzeri və maşını dəyişməz saxlayaraq eyni səhifəni ikinci çıxışdan müqayisə edin. Nəticə çıxış ünvanını izləyirsə, sayt həmin ünvana fərqli yanaşır və heç bir müştəri konfiqurasiyası bunu dəyişməyəcək. Bloklama əvəzinə brauzerinizi izləyirsə, səbəb genişlənmədə, saxlanmış proxy-də və ya həlledici ayarındadır. İki işə salma bu izahatları ucuz ayırır.

Yalnız brauzerdə baş veren nasazlıqlar erkən yoxlamaq üçün kifayət qədər geniş yayılıb. Bir dəstəklənən brauzerdə yüklənib digərində uğursuz olan səhifə profil vəziyyətinə, məzmun bloklayıcısına və ya brauzerin öz içində konfiqurasiya edilmiş şifrəli DNS-ə işarə edir. Chrome-un təhlükəsiz DNS üzrə təlimatları bu ayarın harada olduğunu göstərir və onu dəstəklənən idarəetmə ilə dəyişmək cihazı sıfırlamaqdan yaxşıdır.

Yalnız böyük ötürmələr ilişib qalanda paket ölçüsünə baxın

Başlığını çəkib sonra ilişib qalan səhifənin imzası heç başlamayan səhifədən fərqlidir. Kiçik cavablar keçə bilər, halbuki tam ölçülü yük göndərənə siqnal verə bilməyən bir yerdə atılır və yoldan MTU nasazlığı brauzerdən belə görünür. Filtrləmə haqqında nəzəriyyə qurmazdan əvvəl kiçik sorğunu və böyüyü eyni hosta müqayisə edin. Yolun MTU aşkarlanması yoldakı ən kiçik halqanın ölçüsünü öyrənməlidir və filtrlənmiş şəbəkələrin adətən atdığı ICMP cavablarından asılıdır.

Bu fərziyyəni bir ping əvəzinə ölçü taraması ilə yoxlayın. Sabit yük ölçüsündə başlayan nasazlıq güclü sübutdur, yerini dəyişən nasazlıq isə deyil.

Düzəlişi uğursuz olan sorğuda təsdiqləyin

İlkin əməliyyatı yenidən yoxlayın, ana səhifəni deyil, çünki keşlənmiş qabıq çəkilə bilər, halbuki girişdən sonrakı API çağırışı hələ də uğursuz olur. Aşağıdakı əmrlər ad həllini, kiçik sorğunu və böyüyü eyni hosta ayırır. Host adını və yolu həqiqətən sınmış sorğudakılarla əvəz edin.

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

Əgər dig cavabı brauzerin istifadə etdiyindən fərqlidirsə, dəyişən həlledicidir və brauzerin öz DNS ayarı baxmalı olduğunuz yerdir. Kiçik sorğu status qaytararkən böyük ilişib qalırsa, paket ölçüsü budağını işləyin. İkisi də vaxtı keçərsə, çıxış yolu və saytın o ünvana münasibəti yenidən masadadır.

İlkin sorğunu uğurlu edən dəyişikliyi saxlayın və qalanı ləğv edin. Brauzer, həlledici və müştəridə eyni vaxtda edilən dəyişikliklər yığını hansının əhəmiyyətli olduğunu deyə bilməyəcəyinizə səbəb olur.