VPN serverini özünüz işlətdiyinizdə kimə etibar edirsiniz

Öz hostinqi sizə operator rolunu verir: proqram təminatını, konfiqurasiyanı, yeniləmə cədvəlini və öz xidmətinizin nə qeyd etdiyini siz seçirsiniz. Etmədiyi şey digər tərəfləri bağlantıdan çıxarmaqdır. Giriş şəbəkəniz paketləri daşımağa davam edir, hostinq təchizatçınız maşını idarə etməyə davam edir, həlledici sorğuları cavablandırmağa davam edir və təyinat hələ də sorğu görür. Bunlardan hansını həqiqətən dəyişdiyinizi bilmək bütün məşqdir.

Addım 1: tərəfləri siyahıya alın

Real yerləşdirmədəki hər tərəfi sadalayın: cihazınız, qoşulduğunuz şəbəkə, VPN hostu, DNS həlledicisi və təyinat xidməti. Hər biri üçün nəyi müşahidə edə biləcəyini və hansı parametrləri sizin idarə etdiyinizi qeyd edin.

Bu cədvəl anonimlik barədə hər hansı iddiadan daha faydalıdır, çünki nəzarətin həqiqətən harada dəyişdiyini göstərir. Hostun konfiqurasiyasını və qeydlərini siz idarə edirsiniz. Giriş şəbəkəsinin bağlantınıza baxışını idarə etmirsiniz və təyinatın hesabınız barədə nə qeyd etdiyini də idarə etmirsiniz.

Ev son nöqtəsi üçün əhatə olunan trafik adətən həmin evin giriş bağlantısından çıxır. Təyinatınızın gördüyü çıxış ünvanı ev təsərrüfatının ünvanıdır; bu topologiya ilə bağlı faktdır, proqram təminatında qüsur deyil. Dəyişmək istədiyiniz ünvan məhz budursa, ev serveri bunu edə bilməz. Başqa yerdə çıxışa ehtiyacınız var.

Addım 2: nə qazandığınızı yazın

Yerləşdirilmiş konfiqurasiyanı nəzərdən keçirə, hansı cihazların qoşula biləcəyini qərarlaşdıra, diaqnostika siyasəti təyin edə və seçdiyiniz qeydləri apara bilərsiniz. Bunlar onları saxladığınız zaman real nəzarətlərdir və öz hostinqinin dürüst səbəbi budur.

Onlar həm də şərtlidir. İstifadə olunmayan standart parametr və sınanmamış ehtiyat nüsxə protokolun təqdim etdiyi xüsusiyyətlər deyil; bunlar niyyətlərdir. Nəzarəti onu sübut edən testlə birlikdə yazın, əks halda sayılmır.

Addım 3: texniki xidmət siyahısını qəbul edin

Siyahı qısa və amansızdır: administrator hesabını qoruyun, server açarlarını qoruyun, müştəri kimliklərini verin və ləğv edin, ehtiyat nüsxələri saxlayın, itirilmiş cihazları çıxarın və uğursuz tuneldən asılı olmayan bərpa yolu saxlayın.

Ləğvetmə öz sətrinə layiqdir. Konfiqurasiyadan çıxardığınız, lakin heç vaxt ləğv etmədiyiniz cihaz hələ də etibarlı kimlik məlumatlarına malikdir və fərq yalnız kimsə onlardan istifadə etdikdə görünür. Çıxarmanı köhnə materialla qoşulmağa cəhd edərək yoxlayın.

Ehtiyat nüsxələr də eyni rəftarı tələb edir. Birini ehtiyat hostda bərpa edin və tunelin eyni kimliklərlə qalxdığını təsdiqləyin. Heç vaxt bərpa etmədiyiniz ehtiyat nüsxə fayldır, bərpa planı deyil.

Addım 4: anonimlik fərziyyəsindən əl çəkin

Serveri işlətmək brauzerinizi anonim etmir. Saytlar hələ də hesab məlumatı və kukilər alır, HTTPS isə tətbiq məlumatlarını tuneldən asılı olmayaraq öz yolunda qoruyur.

Daha incə bir təsir də var: yalnız sizin istifadə etdiyiniz ünvan istifadənizlə əlaqələndirilən sabit siqnala çevrilə bilər. Kommersiya çıxışı yad adamlarla paylaşılır; bu, məxfilik üçün bir baxımdan pis, digər baxımdan yaxşıdır. Öz ünvanınız unikaldır və bu, həmin mübadiləni tərsinə çevirir.

Məqsəd əlaqələndirilməsi çətin olmaqdırsa, öz hostinqi bunu çətinləşdirmək əvəzinə asanlaşdıra bilər. Bir axşam sərf etməzdən əvvəl hansı xüsusiyyəti həqiqətən istədiyinizə qərar verin. Unikallıq xərcdir, xüsusiyyət deyil və öz hostinqi haqqında əksər mətnlərdə görünmür. Onu 1-ci addımın tərəf cədvəlinə yazın, mübadilə görünən olur.

Addım 5: göstərilən səbəbə görə seçin

Öz şəbəkənizə şəxsi giriş, konfiqurasiya nəzarəti, konkret marşrutlaşdırma tələbi və ya təchizatçının siyasətindən asılısızlıq hamısı yaxşı səbəblərdir. Uyğun olanı yazın və işlədiyini göstərəcək testi dizayn edin.

Sonra darıxdırıcı hissələri yoxlayın: host yamaqlanıbmı, köhnə açarlar getdimi, saxlama sənədləşdirdiyiniz kimidirmi və nasazlıqdan sonra xidməti bərpa edə bilirsinizmi? Bu dörd cavab etimad modelini protokolun adından qat-qat yaxşı təsvir edir.

Addım 6: çıxışı planlaşdırın

Hostdan necə köçəcəyinizə əvvəlcədən qərar verin: konfiqurasiya harada yaşayır, müştəri profilləri necə yenidən verilir və saxladığınız qeydlərə nə olur. Çıxış planı olmayan öz hostinqli xidmət çıxara bilməyəcəyiniz asılılığa çevrilir.

AWS-in ümumi məsuliyyət modeli başqa yerlərdə də faydalı şablondur, çünki eyni sualı tələb edir: hansı təbəqə sizindir və hansı başqasına aiddir. 1-ci addımdakı hər tərəf üçün cavablandırın və etimad modeli şüar olmaqdan çıxır.