SSHFS quraşdırma nöqtəsi VPN üzərində istifadəçi sessiyasına məxsus olmalıdırmı?

VPN işə düşdükdən sonra paylaşılan qovluğun quraşdırılması asanlıqla qarışdırılan iki kimliyi əhatə edir: şəbəkəni konfiqurasiya etməyə icazə verilən komponent və fayl serverinə daxil olmağa icazə verilən hesab. Onlar nadir hallarda eyni olur. Root sahibliyindəki VPN qarmağı masaüstü istifadəçisinin SSHFS quraşdırmasına başlamaq üçün pis yerdir, çünki nə istifadəçinin agentinə, nə də nəzərdə tutulan quraşdırma sahibliyinə malikdir. Sahibliyi əvvəlcə düzgün qurmaq tetikləyicini sadə edir.

İki kimlik, iki ayrı icazə

VPN müştərisi marşrutları və interfeysləri dəyişmək üçün imtiyazlara ehtiyac duyur. SSHFS quraşdırması fayl serverinin qəbul etdiyi SSH kimliyinə və faylları oxuyacaq hesaba məxsus FUSE quraşdırmasına ehtiyac duyur. Root kimi işləyən bir skript birinci tələbi ödəyir və ikincisini səssizcə pozur.

Root kimi quraşdırma faylları masaüstü sessiyasından kənarda və bəlkə də istifadəçinin açarını saxlayan agentə çıxış olmadan qoyur. Quraşdırma mövcuddur, istifadəçi onun vasitəsilə yaza bilmir və nasazlıq server tərəfində icazə problemi kimi görünür. Bu səhv diaqnoz bir günün yarısına və yaddaş komandasına biletə başa gəlir.

Hər hansı avtomatlaşdırma yazmazdan əvvəl quraşdırmanın hansı hesaba məxsus olduğunu qərar verin, çünki bu seçim tetikləyicinin harada yaşadığını və hansı etimadnamələrə çata biləcəyini müəyyən edir.

Əvvəlcə əl ilə istifadəçiyə məxsus quraşdırma yaradın

Boş quraşdırma nöqtəsi olan daxil olmuş istifadəçidən, icazəli SSH hesabından və tunel vasitəsilə serverə işləyən yoldan başlayın. Əl ilə quraşdırma hər hansı avtomatlaşdırmanın təkrar etməli olduğu əsası qurur.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Adlar nümunədir, ona görə serverinizin həqiqətən təqdim etdiyi hostu və ixrac yolunu əvəz edin. Host açarını həmin ilk bağlantıda təsdiqlənmiş proseslə yoxlayın. Nəzərə alın ki, VPN hesabının parolu avtomatik olaraq yaddaş hesabının etimadnaməsi deyil və bu, uğursuz cəhdlərin ümumi səbəbidir.

Onu adi istifadəçi kimi, həmin istifadəçiyə məxsus quraşdırma nöqtəsi ilə işlədin. Standart olaraq fayllara yalnız quraşdıran hesab çatır və allow_other bu sərhədi hər yerli istifadəçiyə genişləndirir. Bu, girişin qəsdən genişləndirilməsidir, avtomatlaşdırma üçün bir hiylə deyil.

Tetikləyicinin eyni sessiya kontekstində hərəkət etməsinə imkan verin

Dəstəklənən VPN hadisə inteqrasiyasının istifadəçi sessiyası hərəkətini işə salmasını istəyin, imtiyazlı callback-in masaüstü etimadnaməsini borc ala biləcəyini güman etmək əvəzinə. Tetikləyicini təsadüfən tun0 adlanan hər hansı interfeysə deyil, nəzərdə tutulan bağlantı identifikatoruna bağlayın. Səhv şeyə uyğun gələn dispetçer qaydası hər şəbəkə dəyişikliyində işə düşür, o cümlədən bu quraşdırma ilə heç bir əlaqəsi olmayanlarda.

Hərəkət gözlənilən host adını təsdiqləməli, mövcud quraşdırmanı qeyd etməli və bir məhdud cəhd etməlidir. Hər neçə saniyədə yeni SSHFS prosesi başladan və ya server işləmədiyi halda etimadnamə sorğusunu təkrarlayan sorğu dövrəsi qısa kəsintini yığın-yığın ilişmiş proseslərə çevirir. Cəhdi bir timeout və bir tək təkrar cəhdlə məhdudlaşdırın.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

Birinci əmr dispetçerin uyğunlaşdırmalı olduğu bağlantı identifikatorunu verir. Digər ikisi artıq bir cəhdin işləyib-işləmədiyini göstərir və bu, dublikatların qarşısını alan yoxlamadır.

Nəzarətsiz xidmət öz icra kontekstində öz təsdiqlənmiş etimadnaməsinə və host yoxlama qaydasına ehtiyac duyur. O, qrafik agentin kilidinin açıq olduğunu güman edə bilməz və onu açmağa çalışmamalıdır.

Təmizləməni məcbur etməzdən əvvəl ayırmanı planlaşdırın

Planlaşdırılmış ayırma üçün fayl əməliyyatlarını bitirin və quraşdıran istifadəçinin öz iş axınından ayırın. Prosesə deyil, quraşdırma nöqtəsinə hədəflənin və uğur barədə məlumat verməzdən əvvəl nəticəni təsdiqləyin.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

Yalnız bu iş axınının yaratdığı quraşdırmanı ayırın. Əgər məşğuldursa, bu tətbiq qərarıdır: qarmağın uğur qaytarması üçün edilən məcburi ayırma məlumat itkisini qarşısını almaq əvəzinə gizlədir.

Gözlənilməz itki fərqli davranır. SSHFS sənədləşdirir ki, şəbəkə kəsintisi fayl sistemi əməliyyatını bloklaya bilər və reconnect seçimi nəqliyyatı bərpa edir, lakin tutacaqları bərpa etmir: yenidən qoşulmadan əvvəl açılmış fayl növbəti yazıda uğursuz ola bilər və kəsilmiş yazı qorunmur. Bu fərq bir faylı saatlarla açıq saxlayan redaktorlar üçün ən çox əhəmiyyət daşıyır. Bərpanı güman etmək əvəzinə yenidən açma addımı planlaşdırın.

Davranışı etibar etməzdən əvvəl birdəfəlik fayllarla sınaqdan keçirin. Tunel qayıtdıqdan sonra yenidən görünən qovluq əvvəlki tutacaqların və ya yadda saxlanılmamış işin sağ qaldığını sübut etmir.