VPN асаалттай үед апп ажиллах ёсгүй: үүнийг юу хэрэгжүүлдэг

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

Домог: kill switch програмуудыг эхлэхэд саад болдог

Kill switch нь урсгалын хяналт бөгөөд үүнд шударга: туннелийн төлөвөөр пакетийг зөвшөөрөх эсвэл татгалздаг. Тэдний аль нь ч программыг эхлүүлэхээс татгалздаггүй, аль нь ч аль гүйцэтгэх файл сокет нээснийг шалгадаггүй. Ширээний товчлол, товлосон даалгавар, арын туслах бүгд аппын нэрийг мэддэг зүйлээр дамжихгүйгээр сүлжээнд хүрдэг. Эдгээр хоёр механизмын хоорондын зай бол будлианы ихэнх нь амьдардаг газар.

Програм эхэлж болох эсэхийг үнэхээр шийддэг зохион байгуулалт бол аппын хяналт юм. Windows-д энэ нь AppLocker эсвэл WDAC гэсэн үг, удирддаг macOS-д төхөөрөмжийн профайлаар хэрэгжүүлсэн зөвшөөрөгдсөн жагсаалт гэсэн үг. Хоёулаа туннелиас хамааралгүй, тиймээс хоёр шаардлагыг нэг тасалбарт нэгтгээд дараа нь аль нь ч биелдэггүй.

Хэрэгслийн нэрийг өгөхөөс өмнө горимын нэрийг өг

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

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

Хоёр талын зөрчил үнэхээр юу хийдэг

Үнэхээр systemd удирддаг хоёр үйлчилгээний хувьд Conflicts= тэгш хэмтэй: нэгийг эхлүүлэх нь нөгөөг зогсоодог. Нэгжийн лавлагаа энэ зан төлөвийг баримтжуулж, нэг нь зогсолтыг дуусгах ёстой үед нөгөө нь эхлэхээс өмнө тодорхой дарааллыг тусад нь шаарддаг. Тэр дарааллын бичлэггүйгээр зогсолт ба эхлэл өрсөлдөж, үр дүн цаг хугацаанаас хамаарна.

Энэ бол хориглох жагсаалт биш. Хамаарлыг эсрэгээр холбоход аппыг эхлүүлэх нь оронд нь VPN-г зогсоодог бөгөөд туннель урьдчилан таамаглах боломжтой мөчид өөрөө салгах үед сэжиглэх ёстой гэмтэл нь энэ юм. Ширээний апп нь systemd нэгж биш, NetworkManager холболт ч нэгж биш, тиймээс энэ загвар нь өөрөө боосон үйлчилгээнд л ажиллана.

Эхний ажиллагааг бус шилжилтүүдийг шалга

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

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

Сессийн үеэр дахин эхлүүлэх нь бүрхүүлд суурилсан дизайныг илчилдэг тохиолдол, учир нь ширээнээс эхэлсэн товчлол эхлүүлэх скрипттэй хэзээ ч зөвлөлддөггүй. Хэрэв энэ тойрч гарах нь чухал бол хэрэгжүүлэлт нь аппын хяналтад хамаарна, VPN клиентэд биш. Сессийн төгсгөлийг ч баримтжуулж, орох үед зогсоосон процесс бүрийг дахин нээхийн оронд санаатай үргэлжлүүлэхийг илүүд үз. Шилжилт бүрийн үр дүнг нэгжийн файлуудыг хадгалдаг тэмдэглэлд бич.