გამორთვა თუ გათიშვა: VPN-ის ორი განსხვავებული შედეგი

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

კლიენტის დოკუმენტაცია ერთადერთი საიმედო ადგილია იმის გასაგებად, რომელი რომელია.

ოთხი კონტროლი, შესაძლოა ოთხი ქცევა

გათიშვა, როგორც წესი, შლის გვირაბს, სანამ კლიენტი მეხსიერებაში რჩება, რაც ნიშნავს, რომ სერვისმა, სისტემური სარკმლის კომპონენტმა ან kill switch-ის წესმა შეიძლება დაწკაპუნებას გადაიტანოს. შემდეგ ბევრი კლიენტი აგრძელებს ტრაფიკის ბლოკირებას, რადგან მათი პოლიტიკა ამბობს, რომ მოწყობილობა არ უნდა დაბრუნდეს პირდაპირ წვდომაზე, სანამ კლიენტი იქ არის. ეს ქცევა გატეხილ ქსელს ჰგავს და განზრახ დაცვაა.

გამორთვის მიზანი აპლიკაციის დასრულებაა და კარგად მოქცეული კლიენტი გასვლისას საკუთარ წესებს შლის. ზოგიერთი გადაწყვეტა სამაგიეროდ ცალკე დამხმარეს ტოვებს, რომელიც პოლიტიკას ახორციელებს, და ეს არჩევანია და არა ხარვეზი. ფანჯრის დახურვა ინტერფეისის მოქმედებაა გვირაბზე გარკვეული გავლენის გარეშე, ხოლო პაუზა, სადაც ის შემოთავაზებულია, მეოთხე ქცევაა საკუთარი წესებით.

სერვერის მხრიდან შეფერხება სრულიად მეხუთე გზაა და სწორედ მას ხვდებიან მომხმარებლები პრაქტიკაში ყველაზე ხშირად.

წაიკითხეთ მდგომარეობა ყოველ მოქმედებამდე და შემდეგ

მოქმედებამდე ჩაიწერეთ პროცესების სია, სერვისის მდგომარეობა და firewall-ის წესები, შემდეგ გაიმეორეთ ჩაწერა დაუყოვნებლივ. ორი სიის შედარება გვიჩვენებს, რა გააკეთა კონტროლმა სინამდვილეში, ინტერფეისის საკუთარ აღწერაზე დაყრდნობის გარეშე.

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

თუ წესები პროცესთან ერთად ქრება, ისინი კლიენტის იყო. თუ წესები რჩება, როცა პროცესი წავიდა, პოლიტიკას სხვა რაღაც ახორციელებს, და ამ კომპონენტის პოვნა ნებისმიერ ცვლილებამდე მოდის. ჩაიწერეთ სერვისის მდგომარეობა იმავე მომენტში, რადგან გაჩერებული ინტერფეისი სისტემურ სერვისზე არაფერს ამბობს.

ხელით გათიშვა ავარია არ არის

გათიშვა გადის განკუთვნილ გამორთვის გზას, ავარია კი გვერდს უვლის. ამიტომ ერთის შედეგები მეორეზე არ გადადის, შესაბამისად მენიუს ერთეულის გამოყენებული ტესტი ვერ დაადასტურებს მტკიცებას ქცევის შესახებ, როცა კლიენტი კვდება.

ანალოგიურად, ავარია არაფერს ამბობს დამტკიცებულ დროებით პაუზაზე. ეს სამი კითხვა ცალ-ცალკე შეინახეთ ტესტის გეგმაში და ყველაფერში, რაც შემდეგ დაიწერება. გამორთვის გზა ასევე ხსნის, რატომ შეიძლება სუფთა გასვლამ წაშალოს წესები, რომლებსაც ავარია ტოვებს. იგივე ღილაკი, სხვა კოდი, სხვა მტკიცებულება.

აირჩიეთ ის მიუწვდომელი მდგომარეობა, რომელიც ნამდვილად გჭირდებათ

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

თუ მიზანი ჩვეულებრივი პირდაპირი წვდომაა, გამოიყენეთ დოკუმენტირებული კონტროლი პროცესების მოკვლის ან მთელი firewall-ის გამორთვის ნაცვლად. შეწყვეტილი გასვლის დატოვებული მოძველებული წესები განზრახ ჩაკეტვისგან განსხვავებული პრობლემაა და მათ სხვა აღდგენა სჭირდებათ.

ჩაწერეთ, რომელი კომპონენტი გაჩერდა: გვირაბი, ხილული აპლიკაცია თუ პოლიტიკის აღმსრულებელი ფენა. ეს ერთი წინადადება ხელს უშლის ამ კონტროლების მიერ შექმნილი დაბნეულობის უმეტეს ნაწილს.