აპლიკაცია არ უნდა მუშაობდეს, როცა VPN ჩართულია: რა აიძულებს ამას

Kill switch-ები და გადაფარვის აკრძალვის წესები საწინააღმდეგო მიმართულებებს მიუთითებენ, რაც ხსნის, თუ რატომ არ გამოხატავს ჩვეულებრივი VPN პარამეტრები მეორეს. Kill switch რეაგირებს ჩამოვარდნილ გვირაბზე, ხოლო ეს მოთხოვნა რეაგირებს ზევით მდგარ გვირაბზე და აპლიკაციას სურათიდან მიღმა ტოვებს. ერთი დიზაინის გადაწყვეტილება უმეტესობას წყვეტს: ჩერდება აპლიკაცია, ეკრძალება მისი გაშვება, თუ უბრალოდ ერთმევა ქსელში წვდომა. აირჩიეთ ეს ფენა, სანამ firewall-ის წესს ან პროცესების მკვლელ ციკლს მიხვდებით, რადგან დაკვირვებით აღსრულებული წესი ყოველ გაშვებაზე ფანჯარას ჟონავს.

მითი: 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 კლიენტს. დააფიქსირეთ სესიის დასრულებაც და ამჯობინეთ განზრახ გაგრძელება შესვლისას გაჩერებული ყოველი პროცესის ხელახლა გახსნას. ჩაწერეთ ყოველი გადასვლის შედეგი იმავე ჩანაწერში, სადაც ერთეულის ფაილები ინახება.