VPN yenidən qoşulduqdan sonra proksi hələ də köhnə tunel ünvanındadır?

VPN müştərisini yenidən başlatmaq yalnız tunelin geri qayıtdığını sübut edir. Bu, onun içindən çıxmaq əmri verilmiş proksi barədə heç nə demir. Squid, tinyproxy və digər forvarderlərin əksəriyyəti başlanğıcda həll etdikləri yerli mənbə ünvanını nə isə onları yenidən yükləməyə məcbur edənə qədər saxlayır. Yenidən qoşulma yeni tunel ünvanı verdikdə forvarder ya hər çıxan bağlantıda uğursuz olur, ya da adi marşrutunuzdan çıxmağa başlayır.

İkinci nasazlıq təhlükəli olanıdır: tunel işləyir, səhifələr açılır və yalnız çıxış ünvanı səhvdir.

Tuneldən deyil, dinləyicidən başlayın

İşdə üç ünvan var və yenidən qoşulma onların yalnız bəzilərini dəyişir. Dinləyici brauzerinizin yönəldiyi yerdir, adətən 127.0.0.1 və ya LAN ünvanı, və tunelin dəyişməsi onu maraqlandırmır. Çıxan yerli mənbə forvarderin növbəti hopa zəng edərkən nüvədən istifadə etməsini xahiş etdiyi ünvandır və tunel cihazına bağlıdır. İctimai çıxış isə veb serverin qeyd etdiyi ünvandır və bir neçə hop aralıda yerləşən tərcümə edilmiş ünvan ola bilər.

İctimai IP axtarışı yalnız son suala cavab verir. O, forvarderin hansı yerli ünvana bağlanmalı olduğunu deyə bilməz, çünki bir ictimai çıxış bir neçə daxili mənbəni gizlədə bilər. Ünvanı bağlantının sahibindən oxuyun: müştərinin status çıxışı, interfeysin özü və ya tunelin yaşadığı ad fəzası. Adı tunelə bənzəyən ilk interfeysi götürmək ikinci profil yaranan kimi səhv cavab verir.

Konteyner və ad fəzası düzənləri bu fərziyyəni səssizcə pozur. Bir şəbəkə ad fəzasındakı forvarder başqasında mövcud olan tunelə bağlana bilməz və heç bir konfiqurasiya redaktəsi bunu düzəltmir.

Nəyisə redaktə etməzdən əvvəl dörd yoxlama

Bunları sıra ilə keçin. Uğursuz olan ilk yoxlama dayandığınız yerdir, çünki sonrakılar əvvəlkilərin doğru olduğunu fərz edir.

1. İstifadədə olan tunelin proksinin ətrafında qurulduğu profil olduğunu təsdiqləyin, özbaşına qoşulmuş ikinci profil deyil.
2. Həmin cihazda hazırda olan ünvanı çap edin və işləyən konfiqurasiyadakı ünvanla müqayisə edin.
3. Forvarderdən diskdəki faylın iddia etdiyini deyil, həll etdiyi mənbəyi soruşun.
4. Forvarderdən gələn trafikin həqiqətən gözlədiyiniz marşrutlaşdırma və firewall siyasətinə tabe olduğunu təsdiqləyin.

Cihaz ünvanı asandır: ip -4 addr show dev tun0 cari ünvanı çap edir, ip -4 route get 1.1.1.1 isə nüvənin həmin təyinat üçün hansı interfeysi seçəcəyini göstərir. Dəqiq ünvana bağlanan forvarder ünvan yox olduqda yüksək səslə uğursuz olur. Cihaza bağlanan və ya defolt mənbəyə qayıdan forvarder isə işləməyə davam edir və sızır, sakit nəticə də budur.

Sənədləri işlətdiyiniz buraxılışa uyğunlaşdırın, ən yuxarı axtarış nəticəsinə deyil. Squid-in çıxan ünvan direktivi v7 və daha əvvəlki versiyalar üçün sənədləşdirilib və v8 sənədi orada bu direktivin mövcud olmadığını açıq deyir, ona görə onun ətrafında qurulan skript bu sərhədi keçmir (Squid tcp_outgoing_address istinadı). Hər hansı şeyi yenidən yükləməzdən əvvəl məhsulun öz parseri ilə yoxlayın: squid -k parse xətaları bildirir və işləyən prosesə toxunmadan çıxır.

Hər tuneli nömrələyin və köhnə dəyişdirmələri atın

Yenidən qoşulma bir ötürmədir və ötürmələrə sıra lazımdır. Hər müşahidə edilən bağlantını hər uğurlu qurulmada artan sayğac və ya vaxt damğası ilə işarələyin, sonra bu işarəni namizəd konfiqurasiyada daşıyın. Namizəddəki işarə cari işarədən köhnə olduqda namizədi tətbiq etmək əvəzinə atın, çünki əvvəlki tunel üçün yazılmış gecikmiş yeniləmə əks halda cari tunelin parametrlərini üzərinə yazacaq. Hadisə partlamalarını birləşdirin ki, titrəyən xətt on beş yerinə bir keçid yaratsın.

İşi dörd hərəkətdə sıralayın: köhnə çıxış vəziyyətini etibarsız edin, bağlantı sahibinin tamamlanma bildirməsini gözləyin, yalnız idarə olunan fraqmenti qurun, sonra xidmət meneceri vasitəsilə yoxlayın və aktivləşdirin. Bütün faylı iki ünvan dəyərindən yenidən yaratmaq dinləyici məhdudiyyətlərinin, autentifikasiyanın və təyinat siyasətinin səssizcə yox olmasının yoludur. Qəsdən dayandırmaya da hörmət edin. İstifadəçinin söndürdüyü tunelə zəng etməyə davam edən köməkçi davamlılıq deyil, xətadır.

Açıq soketlər yeni ünvanı izləməyəcək

Forvarderin yenidən konfiqurasiyası artıq qurulmuş bağlantılar barədə heç nə demir. Onların boşalacağı və ya öləcəyi məhsuldan asılıdır, ona görə fərz etmək yerinə davranışı müşahidə edin.

Dəyişdirmədən əvvəl açılmış soket üzərindən xidmət edilən sorğu yeni konfiqurasiya düzgün olsa belə köhnə yoldan çıxır. Bu vacibdirsə açıq qərar verin: qısa boşalma pəncərəsinə icazə verin və yeni iş qəbul etməyi dayandırın, ya da köhnə soketləri bağlayın və xətaları qəbul edin. Sonra təzə bağlantı ilə sınayın və bu nəticəni boşalma yoxlamasından ayrı saxlayın. Mənbə bağlaması da təhlükəsizlik sərhədi deyil. Trafik heç vaxt adi marşruta toxunmamalıdırsa, bunu işarələr və firewall qaydaları ilə tətbiq edin, DNS və IPv6 daxil olmaqla, belə ki uğursuz yenidən yükləmə proksini açıq yerinə açıq şəkildə söndürülmüş saxlasın.

Yeni çıxışı təzə sorğu ilə sübut edin

Vacib olan aktivləşdirmədən sonra açılan sorğudur, ping deyil və artıq keşlənmiş səhifə deyil. Proksidən real URL istəyin və qarşı tərəfin bildirdiyi çıxış ünvanını oxuyun, sonra provayder birini təqdim edəndə müştərinin tunelə dair öz baxışı ilə müqayisə edin.

Təhlili, yenidən yükləməni və sorğunu ayrı əmrlər kimi saxlayın ki, uğursuzluq tək bir addımı göstərsin. İlk ikisi uğursuz olduqda heç nəyi dəyişmir, buna görə də yenidən başlatmadan əvvəl işləyirlər.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Yenidən yükləmə uğursuz olarsa, xidməti dayandırın və fraqmenti düzəldin; köhnə çıxışla xidmət edən proksi qısa fasilədən pisdir. Yenidən yükləmə uğurlu olub təzə sorğu yenə gözlənilməz yerdən çıxırsa, ünvanları yenidən redaktə etmək yerinə marşrutlaşdırma yoxlamasına qayıdın. Yoxladığınız tunel nəslini qeyd edin ki, növbəti yenidən qoşulmanın müqayisə üçün konkret bir şeyi olsun.