OpenVPN əvvəlcədən yaradılmış tun: iki sahiblik modelini müqayisə edin

Kimsə tun1 interfeysini əvvəlcədən yaradıb, profil dev tun1 deyir, və bağlantı hələ də qurulmur. Adın hostda mövcud olması demək olar ki, heç nə demir, çünki qoşulma ad fəzasından, cihaz növündən, keçidin kimə aid olduğundan və demonun nəyə icazəsi olduğundan asılıdır. Cihazın təkrar istifadəsi həm də standart konfiqurasiyanın gizlətdiyi qərarı məcburi edir: ünvanları və marşrutları hansı komponentin yazması. İki quruluşun uğursuzluq rejimləri konfiqurasiya sətirlərindən qat-qat çox fərqlənir, ona görə profil redaktə etməzdən əvvəl qərar verin.

Ad qoşulma deyil

dev tun1 həmin adlı interfeysi OpenVPN -dən istəyir, və ənənəvi istifadəçi fəzası qurğuları onu açmağa çalışacaq. Əgər ad adi tun və ya tap nümunəsinə uyğun gəlmirsə, profil həmçinin uyğun bir dev-type tələb edir, çünki növ heç vaxt sətirdən çıxarılmır. TAP cihazı fərqli etiketli TUN cihazı deyil: səhv olanı qoşmaq ya tamamilə uğursuz olur, ya da heç kimin gözləmədiyi kadrları daşıyan keçid yaradır. Növü hər şeydən əvvəl yoxlayın, çünki sonrakı hər yoxlama iki tərəfin bu barədə razı olduğunu fərz edir. Bundan sonra prosesin cihazı sadəcə görmədiyini, həqiqətən aça bildiyini təsdiqləyin.

dev tun1
dev-type tun

Şəbəkə interfeysi və /dev/net/tun fərqli obyektlərdir: biri ad fəzası daxilində keçid, digəri istifadəçi fəzası proqramının qoşulmaq üçün istifadə etdiyi simvol cihazıdır. Linux TUN/TAP sənədləşməsi həmin qoşulma yolunu və davamlı cihazlar üçün sahiblik qaydalarını təsvir edir. Root shell-in ip link işlədə bilməsi yalnız shell-in imtiyazları olduğunu sübut edir, demonun onları olduğunu yox. Cihaz qovşağının sahibliyi, xidmətin imkanlar dəsti və onun altında işlədiyi istifadəçi açılış uğurlu olmazdan əvvəl hamısı üst-üstə düşməlidir.

Mövcud olub açıla bilməyən cihaz sahiblik problemidir, marşrut problemi deyil. Sazlama zamanı ona belə yanaşın, əks halda günorta heç vaxt problem olmayan marşrut cədvəllərini oxumağa gedir.

Keçidi kim konfiqurasiya edir: iki sahiblik modeli

Birinci modeldə OpenVPN bağlantını qaldırmağın bir hissəsi olaraq ünvanları və marşrutları konfiqurasiya edir. Bu standart davranışdır və haqqında düşünmək ən asanıdır, çünki vəziyyəti tək bir komponent yaradır və yenidən silir. İkinci modeldə interfeys xarici menecerə aiddir və ifconfig-noexec OpenVPN-in ünvan konfiqurasiyası əmrlərini işlətməsini dayandırır və parametrləri əvəzində skriptlərə verir. Sonra menecer düzgün yerli və qarşı tərəf konfiqurasiyasını özü tətbiq etməlidir, bu da seçim adının təklif etdiyindən daha çox işdir. İkisi arasında seçim keçid işləyərkən kimin onu dəyişə bilməsi ilə bağlı sualdır.

ifconfig-noexec yalnız ünvanları əhatə edir: marşrut cədvəlinə toxunulmur və marşrut konfiqurasiyası route-noexec-a aiddir. İki direktivi ayrı sahibləri olan ayrı idarəetmə vasitələri kimi qəbul edin, çünki birini qurub digərini güman etmək yarımkonfiqurasiya edilmiş keçidlərin adi mənbəyidir. Hər təbəqə üçün dəqiq bir sahib seçin, ünvanlar bir yerdə və marşrutlar bir yerdə. Şəbəkə meneceri və VPN köməkçisinin ikisinin də ünvan yazması, bağlantı kəsiləndə qarşı tərəfin hələ də asılı olduğu vəziyyəti silməyin yoludur.

Cihazı əhəmiyyətli olan ad fəzasından yoxlayın

Cihazı VPN prosesinin işlədiyi ad fəzasından yoxlayın, shell-inizin təsadüfən olduğu fəzadan yox. Aşağıdakı iki əmr fərqli suallara cavab verir və fərq hostun konteynerin görə bilmədiyi interfeysi görməsində ortaya çıxır. Onları verilən ardıcıllıqla işlədin, çünki ikincisi yalnız keçidin ümumiyyətlə mövcud olduğunu bildikdən sonra məna kəsb edir.

ip -details link show dev tun1
ip tuntap show

Birinci əmr keçidi nüvənin gördüyü kimi çap edir, bayraqlar və interfeys növü daxil olmaqla, və bununla nəzərdə tutduğunuz cihaz olduğunu təsdiqləyirsiniz. İkinci davamlı tun/tap qeydlərini sadalayır, onlar heç bir proses tutmadan mövcuddur. Öz nəzərdə tutulan sahibini gözləyən interfeys başqa VPN-ə qoşulmuş canlı tuneldən fərqli vəziyyətdir və yalnız ikincisi öz qoşulmanızın niyə uğursuz olduğunu izah edir. Nəyisə dəyişməzdən əvvəl cihazı tutan prosesi tapın, çünki davamlı qeyd və məşğul interfeysin düzəlişləri fərqlidir.

Multiqueue dəstəyi öz tələbləri olan xüsusi sürücü quruluşudur, əlaqəsiz proseslərin bir interfeysi bölüşməsinə icazə deyil. Başqa sahibin canlı sessiyası koordinasiya problemidir və heç bir profil redaktəsi onu həll etmir.

İki fərqli davamlılıq növü

Nüvə davamlılığı və persist-tun asanlıqla qarışdırılan və qarışdırılması bahalı olan ömürləri təsvir edir. Davamlı cihaz hər hansı prosesdən asılı olmadan mövcuddur, ona görə dayanmağa davam edir və növbəti başlamada təkrar istifadə oluna bilər. persist-tun bir OpenVPN prosesi daxilində dəstəklənən yumşaq yenidən başlatmalar boyunca resursları saxlayır, bu daha qısa horizontdur. Heç biri xidmətin dayandırılmasının marşrutları və ünvanları yerində qoyacağına zəmanət vermir və görünən qalan interfeys işləyən şifrəli sessiyanın sübutu deyil.

Backend-i də təsdiqləyin, çünki əvvəlcədən yaradılmış interfeys onu hansı implementasiyanın açacağı barədə heç nə demir. Birbaşa məlumat yolunu daşıyan icma qurğuları dizayn başqa cür deməsə, ondan istifadə etməyə çalışacaq. Versiya keçidi dəstəklədiyi yerlərdə, disable-dco əvəzində istifadəçi fəzası yolunu seçir; köhnə mühərriklər və digər müştərilər belə direktivə malik deyil, ona görə versiya şərtini seçimin yanında saxlayın, tətbiq olunduğunu güman etməyin.

Yalnız başlanğıc sınaqdan keçirildikdə nə pozulur

Sahiblik razılaşması birinci sınaqdan keçib sonuncusunda uğursuz ola bilər, bu da başlanğıcı təkbaşına zəif yoxlama edir. Əvəzində iki keçidi izləyin: yumşaq yenidən başlatma və tam dayanmadan sonra başlama.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Başlanğıc asan haldır: bölmə qalxır, keçid görünür və status çıxışı yüklənən profili adlandırır. Qoşulma demonun cihazı açdığı andır, ona görə keçid yoxlamasını bölmə aktiv olduğunu bildirdikdən sonra işlədin, ondan əvvəl yox. Əgər status hələ aktivləşərkən keçid mövcuddursa, siz hələ heç kimin qoşulmadığı davamlı cihaza baxırsınız, işləyən tunelə yox. Davam etməzdən əvvəl keçiddən real trafik keçirin, çünki istifadə oluna bilən marşrutu olmayan qoşulmuş interfeys hələ də uğursuzluqdur.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Yumşaq yenidən başlatma sessiyanı istifadə oluna bilən və resursları bütöv qoymalıdır; bunu persist-tun edir. Tam dayanma xarici menecerin özünü göstərdiyi yerdir: əgər keçid və ya onun ünvanları dayanmadan sonra qalırsa, onlara başqası sahibdir və bu ya sənədləşdirdiyiniz vəziyyətdir, ya da təzəcə tapdığınız xətadır. Hər iki müşahidəni profilin yanında qeyd edin ki, növbəti dəyişiklik diaqramdan deyil, sübutdan başlasın.