VPN дээрх SSHFS холболтыг хэрэглэгчийн сесс эзэмших ёстой юу?

VPN өссөний дараа хуваалцсан хавтасыг холбох нь амархан андуурагддаг хоёр таних тэмдгийг хамарна: сүлжээг тохируулах зөвшөөрөлтэй бүрэлдэхүүн хэсэг, файлын серверт нэвтрэх зөвшөөрөлтэй бүртгэл. Тэд ховор ижил байдаг. Root эзэмшлийн VPN дэгээ нь ширээний хэрэглэгчийн SSHFS холболтыг эхлүүлэхэд муу газар, учир нь түүнд хэрэглэгчийн агент ч, төлөвлөсөн холболтын эзэмшил ч байхгүй. Эзэмшлийг эхлээд зөв тогтоовол триггер энгийн болно.

Хоёр таних тэмдэг, хоёр тусдаа зөвшөөрөл

VPN клиентэд маршрут, интерфэйс өөрчлөх эрх хэрэгтэй. SSHFS холболтод файлын серверийн хүлээн зөвшөөрдөг SSH таних тэмдэг, файлыг унших бүртгэлийн эзэмшилд байх FUSE холболт хэрэгтэй. Root-оор ажилладаг нэг скрипт эхний шаардлагыг хангаж, хоёр дахьыг чимээгүй эвддэг.

Root-оор холбох нь файлуудыг ширээний сессээс гадна, магадгүй хэрэглэгчийн түлхүүрийг хадгалдаг агент руу нэвтрэх боломжгүй орхидог. Холболт байгаа ч хэрэглэгч түүгээр бичиж чадахгүй, алдаа нь серверийн талын зөвшөөрлийн асуудал мэт харагдана. Тэр буруу онош нь хагас өдөр, хадгалалтын баг руу нэг тасалбар үнэтэй.

Ямар ч автоматжуулалт бичихээс өмнө аль бүртгэл холболтыг эзэмшихээ шийдээрэй, учир нь энэ сонголт триггер хаана амьдрах, ямар итгэмжлэлд хүрэхийг тодорхойлно.

Эхлээд гараар хэрэглэгчийн эзэмшлийн холболт үүсгээрэй

Хоосон холболтын цэг, зөвшөөрөгдсөн SSH бүртгэл, туннелээр сервер рүү ажиллах замтай нэвтэрсэн хэрэглэгчээс эхэл. Гараар холбох нь аливаа автоматжуулалт давтах ёстой суурийг тогтоодог.

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

Нэрс жишээ тул сервер тань үнэхээр санал болгодог хост, экспортын замыг орлуулна уу. Эхний холболт дээр зөвшөөрөгдсөн процессоор хост түлхүүрийг баталгаажуулна уу. VPN бүртгэлийн нууц үг автоматаар хадгалалтын бүртгэлийн итгэмжлэл биш гэдгийг анхаарна уу, энэ нь бүтэлгүй оролдлогын түгээмэл шалтгаан юм.

Үүнийг энгийн хэрэглэгчээр, тэр хэрэглэгчийн эзэмшлийн холболтын цэгтэй ажиллуулна уу. Анхдагчаар холбодог бүртгэл л файлуудад хүрдэг, allow_other нь энэ хязгаарыг орон нутгийн хэрэглэгч бүрт өргөтгөдөг. Энэ нь нэвтрэлтийг зориуд өргөтгөх явдал, автоматжуулалтын тойрч гарах зам биш.

Триггерийг ижил сессийн контекстэд ажиллахыг зөвшөөр

Дэмжигдсэн VPN үйл явдлын интеграц хэрэглэгчийн сессийн үйлдлийг ажиллуулахыг хүсэг, эрх бүхий callback ширээний итгэмжлэлийг зээлж чадна гэж таамаглахын оронд. Триггерийг санамсаргүйгээр tun0 гэж нэрлэгддэг интерфэйс биш, төлөвлөсөн холболтын танигчаар хязгаарла. Буруу зүйлтэй таарсан диспетчерийн дүрэм энэ холболттой огт хамаагүй өөрчлөлтүүдийг оролцуулан сүлжээний өөрчлөлт бүрт ажилладаг.

Үйлдэл нь хүлээгдэж буй хостын нэрийг баталгаажуулж, одоо байгаа холболтыг анзаарч, нэг хязгаарлагдмал оролдлого хийх ёстой. Хэдхэн секунд тутамд шинэ SSHFS процесс эхлүүлдэг эсвэл сервер унтарсан үед итгэмжлэлийн хүсэлтийг давтдаг санал асуулгын давталт богино тасалдлыг гацсан процессуудын овоолго болгоно. Оролдлогыг таймаут, нэг дахин оролдлогоор хязгаарла.

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

Эхний команд нь диспетчер таарах ёстой холболтын танигчийг өгдөг. Бусад хоёр нь оролдлого аль хэдийн явагдаж байгаа эсэхийг харуулдаг бөгөөд энэ нь давхардлыг сэргийлэх шалгалт юм.

Хяналтгүй үйлчилгээ өөрийн гүйцэтгэлийн контекстэд өөрийн батлагдсан итгэмжлэл, өөрийн хостын шалгалттай байх шаардлагатай. Тэд график агентыг түгжээгүй гэж үзэж чадахгүй, нэгийг нээх гэж оролдох ёсгүй.

Хүчээр цэвэрлэхийн өмнө салгалтыг төлөвлө

Төлөвлөсөн салгалтын хувьд файлын үйлдлүүдийг дуусгаж, холбодог хэрэглэгчийн өөрийн ажлын урсгалаас салга. Процесс биш, холболтын цэгийг онилж, амжилтыг мэдээлэхийн өмнө үр дүнг баталгаажуул.

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

Зөвхөн энэ ажлын урсгалаас үүссэн холболтыг салга. Хэрэв завгүй бол энэ нь програмын шийдвэр: дэгээ амжилт буцаахын тулд байдаг хүчээр салгах нь өгөгдлийн алдагдлыг сэргийлэхийн оронд нуудаг.

Гэнэтийн алдагдал өөрөөр ажилладаг. SSHFS сүлжээний тасалдал файлын системийн үйлдлийг блоклож болзошгүй, reconnect сонголт нь бариулыг сэргээхгүйгээр тээврийг сэргээдэг гэж баримтжуулдаг: дахин холбогдохоос өмнө нээсэн файл дараагийн бичилтэд бүтэлгүйтэж болно, тасалдсан бичилт хадгалагдахгүй. Энэ ялгаа нь нэг файлыг хэдэн цагаар нээлттэй байлгадаг редакторуудад хамгийн чухал. Сэргээлтийг таамаглахын оронд дахин нээх алхмыг төлөвлө.

Түүнд найдахаасаа өмнө нэг удаагийн файлуудаар зан төлөвийг шалга. Туннель буцаж ирсний дараа дахин гарч ирдэг хавтас нь өмнөх бариулууд эсвэл хадгалаагүй ажил амьд үлдсэнийг нотолдоггүй.