Always-on VPN თუ kill switch: რომელი ჩართეთ სინამდვილეში?

Always-on VPN ხელახლა ამაგრებს გვირაბს; kill switch წყვეტს, რა შეიძლება გავიდეს მის გარეშე. ხუთი შემოწმება, სანამ ეტიკეტს დაეყრდნობით.

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

შემოწმება 1: დაბლოკვა დამოუკიდებელი გადამრთველია?

Android 10 და უფრო ახალ ვერსიებზე შენახული VPN პროფილი კბილანის ხატულის მიღმა ორ დამოუკიდებელ გადამრთველს ხსნის: Always-on VPN და Block connections without VPN. მხოლოდ მეორეა kill switch. მხოლოდ always-on-ით გვირაბი ნამდვილად ბრუნდება წყვეტის შემდეგ, და მოთხოვნის შუაში მყოფ ნებისმიერ აპს შეუძლია ქსელამდე მისვლა Wi-Fi-ით ან მობილური მონაცემებით, სანამ ეს მოხდება.

მართული მოწყობილობები იმავე გაყოფას ინარჩუნებენ პოლიტიკის API-ში. setAlwaysOnVpnPackage() იღებს პაკეტის სახელს და lockdownEnabled დროშას; ადმინისტრატორმა, რომელიც აყენებს პაკეტს და დროშას false-ზე ტოვებს, ააგო მუდმივი გვირაბი და არა დახურული მოწყობილობა. კონსოლის ფორმულირება იშვიათად ხდის ამ განსხვავებას ხილულს.

მდგომარეობა წაიკითხეთ მოწყობილობიდან და არა კონსოლიდან: adb shell settings get global always_on_vpn_app და adb shell settings get global always_on_vpn_lockdown. თუ პირველი აბრუნებს null, პლატფორმის დონეზე არც ერთი პაკეტი არ არის იძულებით გამოყენებული; თუ მეორე აბრუნებს 0, პლატფორმა არაფერს ბლოკავს. Android VPN-ის სახელმძღვანელო მათ ცალკე შესაძლებლობებად აღწერს და არა ერთ რეჟიმად.

შემოწმება 2: რომელი შრე ფლობს დაბლოკვას?

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

Where you see the labelWhat the label promisesWhat actually blocks
Android VPN profileAlways-on VPNBlock connections without VPN
Android device policyAlways-on packagelockdownEnabled flag
Windows built-in VPNAlways On tunnelOutbound firewall rules
WireGuard for WindowsTunnel serviceBlock untunneled traffic option
wg-quick on LinuxRoute via AllowedIPsYour own nftables or iptables rules

Windows ყველაზე ნათელი მაგალითია ეტიკეტისა, რომელიც არ ბლოკავს. იქ Always On აღწერს გვირაბის მდგრადობას: მოწყობილობის გვირაბი მანქანის ავთენტიფიკაციისთვის, მომხმარებლის გვირაბი შესული ანგარიშისთვის, კონფიგურირებული პროფილის XML-ით ან Add-VpnConnection-ით. ამ პროფილში არაფერი აჩერებს გამავალ პაკეტს, როცა გვირაბი არ არის, და გამავალი ფილტრაცია ნაგულისხმევად ჩართული არ არის, ამიტომ Wi-Fi-ზე მყოფი ლეპტოპი აგრძელებს მუშაობას, როცა VPN გამორთულია.

WireGuard იმავე გზით იყოფა, მაგრამ კლიენტის მიხედვით. WireGuard for Windows-ს აქვს Block untunneled traffic პარამეტრი თითოეული გვირაბისთვის, რომელიც ფილტრის წესებს ამონტაჟებს; Linux-ის ხელსაწყოებს ასეთი გადამრთველი არ აქვთ. wg-quick ამატებს მარშრუტს თითოეული AllowedIPs ჩანაწერისთვის და fwmark წესს, ხოლო wg-quick down ორივეს შლის, ამიტომ ფიზიკური ნაგულისხმევი მარშრუტი ისევ იღებს საქმეს, ერთი პაკეტის დაკარგვის გარეშე.

Apple-ის პლატფორმებზე always-on მოდის, როგორც მართვის პროფილის თვისება ზედამხედველობის ქვეშ მყოფი მოწყობილობებისთვის და გამოიხატება on-demand წესებით და არა მოსანიშნი უჯრით. კითხვა, რომელზეც payload-იდან უნდა ვუპასუხოთ, არის: უარყოფს თუ არა წარუმატებელი გვირაბი ტრაფიკს, თუ მხოლოდ სხვა კავშირს ითხოვს. მენიუს სათაური ამას არ გეტყვით.

შემოწმება 3: გაზომეთ შუალედი და არა ხატული

ოთხი გადასვლა მნიშვნელოვანია და თითოეული სხვანაირად ფუჭდება: ჩატვირთვა სანამ ვინმე შევა, ძილი და გამოღვიძება, გადასვლა Wi-Fi-დან მობილურ მონაცემებზე და კლიენტის კრაში, რომელიც გვირაბის ინტერფეისს ნახევრად კონფიგურირებულს ტოვებს. მათგან ერთზე სუფთა ხელახალი დაკავშირება დანარჩენ სამზე არაფერს ამტკიცებს.

ყველაზე იაფი ტესტი განზრახ აჩერებს გვირაბს და შემდეგ ცდილობს გარეთ გასვლას. როცა გვირაბი გამორთულია, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com-ის მიერ დაბრუნებული 200 ნიშნავს, რომ პოლიტიკა fail-open-ია; დროის ამოწურვა ან უარყოფილი კავშირი ნიშნავს, რომ რაღაც მაინც ბლოკავს. ip route get 1.1.1.1 ასახელებს ინტერფეისს, რომელიც გადაიტანდა პაკეტს, რაც ჩვეულებრივ უფრო ინფორმატიულია, ვიდრე უჯრის ხატული, ხოლო systemctl status wg-quick@wg0 აჩვენებს, სუფთად იქნა თუ არა ინტერფეისი მოცილებული.

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

შემოწმება 4: გამონაკლისები გადაწყვიტეთ სანამ ჩაკეტავთ

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

მინიმალური ფორმა: საბოლოო წერტილი დაშვებულია, დანარჩენი ჩამოგდებული:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

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

შემოწმება 5: ჩაწერეთ, რა დაამტკიცეთ სინამდვილეში

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

სანამ დასრულებულს უწოდებთ:

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

დაკავშირებული სტატიები