Hər OpenVPN peer-inə remote sətri lazımdır? Tam belə deyil

İki peer konfiqurasiyası yan-yana müqayisə olunur, birində remote sətri var, digərində yox, və nəticə onlardan birinin sınıq olduğudur. Bu çıxarış təhlil etməyə dəyəcək qədər tez-tez səhvdir. Direktiv ilk paketin hara göndəriləcəyini təsvir edir. Prosesin başladan müştəri və ya gözləyən şlüz kimi çıxış etdiyini seçmir və hansı tərəfin öz kimliyini digərinə sübut etdiyini də həll etmir.

remote əslində nəyi göstərir

remote qeydi host, istəyə görə port və nəqliyyat, istəyə görə də sıra ilə sınanacaq bir neçə belə qeyd adlandırır.

Onun olmaması qeyri-müəyyən deyil, müəyyən məna daşıyır: proses gözləyir və həmin peer autentifikasiya etmədikcə heç bir ünvandan gələn paketlərlə işləmir. Ona görə də gəzən istifadəçilərə xidmət edən şlüzün onlardan hər hansı birini əvvəlcədən adlandırmağa əsası yoxdur.

Qeydi ünvan münasibəti kimi oxuyun. Uzaq tərəfin etibarlı olub-olmadığına sertifikatlar və yoxlama seçimləri cavab verir, ünvanın yazılmış olması deyil.

Cavabı üç düzülüş həll edir

Gəzən müştəriyə təyinat lazımdır, çünki başlamalıdır və təyinat olmadan şlüzün harada olduğunu bilmir. Çoxmüştəri şlüzünə istifadəçi üzrə təyinat lazım deyil, çünki müştərilər gəlir və autentifikasiya edir. Ucları bilinən qəsdən iki peer-li əlaqədə təyinat bir tərəfdə, hər iki tərəfdə və ya heç birində ola bilər; bu, hansı tərəfin başlamasından asılıdır.

Sabit müştəri ünvanını ümumi şlüzə yapışdırmaq həmin kateqoriyalara məhəl qoymamaqdan doğan səhvdir. Ünvanı qeydə alınmış tək peer üçün işləyir və qalan hər kəsi çaşdırır.

Direktivdə konfiqurasiyanı çoxmüştəri serverinə çevirən heç nə yoxdur və onun mövcudluğu da server roluna mane olmur. OpenVPN 2.6 sənədi istəyə bağlı arqumentləri və remote-un olmaması davranışını ayrı-ayrı sənədləşdirir, bu da onların nə qədər müstəqil olduğuna işarədir.

Nəqliyyat rolları başqa oxdur

TCP-də bir tərəf gözləyir, digəri zəng edir. Bunlar təyinatdan ayrı direktivlərdir və onları qarışdırmaq hər ikisi gözləyən və ya hər ikisi zəng edən cüt yaradır.

TCP mənbə filtri rolu da var; serverin heç vaxt remote ehtiva edə bilməyəcəyi barədə düz ifadənin səhv olmasının səbəbi budur.

UDP-də qurulacaq əlaqə yoxdur, ona görə hər iki uc uyğun UDP nəqliyyatından istifadə edir və direktiv yalnız hara nişan alınacağını deyir. Autentifikasiya olunmuş peer-in ünvan dəyişiklikləri daha çox qeyd əlavə etməklə deyil, xüsusi davranışla idarə olunur. Nəqliyyatı düzgün qurmaq təyinatın bir məna daşımasının şərtidir və ikisini qarışdırmaq inandırıcı görünən və heç vaxt əl sıxışmasını tamamlamayan konfiqurasiyalar yaradır.

Niyə remote-un olmaması açıq qapı deyil

Təyinatı olmayan proses yenə də autentifikasiya etməyən peer-lərdən gələn trafiki rədd edir; insanların olmayan sətri hər kəsə açıq dinləyici kimi oxuyanda qaçırdığı hissə budur.

Autentifikasiya və təyinat müstəqildir və etibar üçün vacib olan birincisidir.

Əks səhv daha təhlükəlidir. Sabit mənbə ünvanı xüsusi və yoxlanması asan olduğu üçün giriş nəzarəti kimi hiss oluna bilər, amma qarşı tərəfin kim olduğuna dair heç nə sübut etmir. Sertifikat yoxlamasını saxlayın və sertifikatı roluna bağlayan kimlik yoxlamalarını saxlayın. Onları ünvan uyğunluğu ilə əvəz etmək real nəzarəti onun görünüşü ilə dəyişir.

Konfiqurasiyanın nəyi fərz etdiyini yazın

Hər tərəf üçün üç şey qeyd edin: ilk paket peer-ə necə çatır, hansı tərəf nəqliyyatı qəbul edə bilər və hər tərəf digəri barədə nəyi yoxlayır.

O fərziyyələr dizayndır. Direktivlər yalnız onların yazılışıdır.

İki fayl fərqlidirsə, birinin səhv olduğunu fərz etmək əvəzinə fərqli fərziyyələr ifadə edib-etmədiklərini yoxlayın. Simmetrik fayl cütü işlək tunel üçün nə zəruri, nə də kafidir və asimmetriya çox vaxt topologiyanı işlədən hissədir.