Kill switch ბლოკავს მთელ ქსელურ ტრაფიკს ყოველთვის, როცა VPN tunnel არ არის აწეული, ასე რომ შენი ჩვეულებრივი კავშირიდან არაფერი ჟონავს, სანამ VPN ირთვება, ხელახლა უერთდება ან ჩავარდა. Always-on მეორე ნახევარია: ის VPN-ს ჩართვისას უშვებს და ყოველი ქსელის ცვლილების შემდეგ აბრუნებს, ისე რომ არაფერს ეხები. Android-ს ორივე ჩაშენებული აქვს, VPN-ის პარამეტრებში: Always-on VPN და Block connections without VPN. Windows-სა და macOS-ზე სისტემური გადამრთველი არ არსებობს, ასე რომ ყველაფერი კლიენტზეა დამოკიდებული - WireGuard-ის Windows აპს აქვს, ბევრ სხვას არა - ან firewall-ის წესებზე, რომლებსაც თავად წერ. iOS შუაშია. რასაც არ უნდა იყენებდე, გატესტე ასე: VPN-ს კავშირი ფეხქვეშ გამოაცალე და უყურე, რა გადის.
ეს მნიშვნელოვანია დროის გამო. გაჟონვის ტესტი, რომელიც მშვიდ დროს ტარდება, იდეალურ შედეგს აჩვენებს; გაჟონვები ხდება იმ წამებში, როცა ლეპტოპს აღვიძებ, wifi-დან მობილურ ინტერნეტზე გადადიხარ, ან სერვერი რესტარტდება.
როდის ძვრება ტრაფიკი გარეთ#
VPN კლიენტი პროგრამაა, და არის მომენტები, როცა ის არ მუშაობს ან არ არის მიერთებული, შენი მოწყობილობა კი სავსებით ონლაინაა.
| მომენტი | რა ხდება დაცვის გარეშე |
|---|---|
| ჩართვა ან შესვლა | აპები სინქრონიზაციას იწყებენ, სანამ VPN კლიენტი ჩაირთვება |
| ახალ ქსელთან მიერთება | ფონური აპები უერთდებიან იმ წამს, როცა ქსელი ჩნდება |
| Wifi-დან მობილურ ინტერნეტზე გადასვლა | Tunnel წყდება; ტრაფიკი ახალ ნაგულისხმევ მარშრუტს მიჰყვება, სანამ ხელახლა არ მიუერთდება |
| ძილის რეჟიმიდან გაღვიძება | Tunnel მოძველებულია; OS ტრაფიკს აგრძელებს, სანამ კლიენტი შეამჩნევს |
| სერვერის რესტარტი ან მიუწვდომლობა | კლიენტი ცდილობს ხელახლა; ამასობაში ტრაფიკი პირდაპირ მიდის |
| კლიენტის ჩავარდნა ან განახლება | მარშრუტისა და DNS-ის პარამეტრები შეიძლება მოიშალოს ან ნახევრად დარჩეს |
თითოეულ შემთხვევაში ექსპოზიცია მოკლეა - წამები, ზოგჯერ წუთი - მაგრამ სწორედ მაშინ აგზავნიან ფოსტის კლიენტები, მესენჯერები, ღრუბლოვანი სინქრონიზაცია და განახლებების შემმოწმებლები პირველ მოთხოვნებს, და ეს მოთხოვნები ლოკალურ ქსელს შენს რეალურ მისამართსა და შენს DNS-ს უჩვენებს. თუ VPN-ს იმიტომ იყენებ, რომ ქსელს არ ენდობი, სწორედ ეს წამებია მნიშვნელოვანი. VPN საჯარო wifi-ზე ხსნის, რას ხედავს ლოკალური ქსელი ამ ფანჯარაში.
Android: Always-on VPN და კავშირების დაბლოკვა VPN-ის გარეშე#
Android ამას სწორად უმკლავდება Android 8-დან. ნებისმიერი VPN აპი, რომელიც სისტემის VPN სერვისზეა აგებული, შეიძლება always-on გახდეს, და ბლოკს თავად სისტემა აღასრულებს.
Pixel-სა და სუფთა Android-ზე: Settings, Network and internet, VPN, შემდეგ გადაცემათა ხატულა VPN აპის გვერდით. Samsung-ის ტელეფონებზე VPN-ების სია არის Settings, Connections, More connection settings, VPN. სხვა მწარმოებლები მას სხვაგან გადაიტანენ; პარამეტრებში "VPN"-ის ძებნა მას პოულობს.
ორი გადამრთველი:
- Always-on VPN - Android VPN-ს ჩართვისას უშვებს და ხელახლა ჩართავს, თუ ის გაჩერდება. Always-on მხოლოდ ერთი აპი შეიძლება იყოს.
- Block connections without VPN - lockdown რეჟიმი. სანამ VPN მიერთებული არ არის, აპებს ქსელი საერთოდ არ აქვთ.
ორივე ჩართულით აპს არაფრის გაგზავნა არ შეუძლია tunnel-ის გარეთ ჩართვისას, ქსელის ცვლილებისას ან ჩავარდნის შემდეგ; ის უბრალოდ ელოდება. ასეთი უნდა იყოს kill switch.
VLESS კლიენტები, როგორიცაა v2rayNG და Hiddify, ამასთან მუშაობს, როცა VPN რეჟიმში არიან, რადგან ამ რეჟიმში ისინი ჩვეულებრივი Android VPN აპებია. მხოლოდ proxy რეჟიმში ისინი ასეთები არ არიან, და always-on პარამეტრები მათზე არ მოქმედებს.
სამი გაფრთხილება:
- Captive portal-ები წყვეტს მუშაობას. ჩართული lockdown-ით სასტუმროს შესვლის გვერდი ვერ იტვირთება, ასე რომ VPN ვერასდროს მიუერთდება. გამორთე ბლოკი, გაიარე portal, მიუერთდი და ისევ ჩართე.
- ერთდროულად ერთი VPN. Always-on VPN შეიძლება ჩანაცვლდეს სხვა VPN აპის ჩართვით, ხოლო firewall ან რეკლამის დამბლოკავი აპი, რომელიც ლოკალურ VPN-ად მუშაობს, მასთან კონფლიქტში შევა.
- Android თავად აგზავნის ცოტას tunnel-ის გარეთ. მკვლევრებმა აჩვენეს, რომ lockdown რეჟიმშიც კი Android თავისი ტრაფიკის ნაწილს - მაგალითად კავშირის შემოწმებებს - VPN-ის გარეთ აგზავნის. Google ამას განზრახულად მიიჩნევს. ადამიანების უმეტესობისთვის ეს რამდენიმე მოთხოვნაა Google-ის სერვერებთან; თუ შენი საფრთხის მოდელი tunnel-ის გარეთ ვერანაირ ტრაფიკს ვერ იღებს, იცოდე, რომ ეს არსებობს.
Windows: დამოკიდებულია კლიენტზე#
Windows-ს მესამე მხარის კლიენტებისთვის ჩაშენებული VPN kill switch არ აქვს. დაცვა კლიენტიდან უნდა მოვიდეს, ჩვეულებრივ Windows Filtering Platform-ის წესების დამატებით, რომლებიც tunnel-ის გარეთ ტრაფიკს ბლოკავს.
| კლიენტი | Kill switch Windows-ზე |
|---|---|
| WireGuard for Windows | "Block untunneled traffic (kill-switch)" ოფცია, ჩანს, როცა tunnel მთელ ტრაფიკს ატარებს (0.0.0.0/0) |
| OpenVPN | ჩაშენებული არ არის; block-outside-dns მხოლოდ სხვა ადაპტერებზე DNS-ს ბლოკავს |
| VLESS კლიენტები | განსხვავდება კლიენტისა და ვერსიის მიხედვით; შეამოწმე პარამეტრებში TUN რეჟიმი და block ან strict-route ოფცია |
ორი რამ, რაც უნდა იცოდე, რომელი კლიენტიც არ უნდა გამოიყენო:
- Proxy რეჟიმი VPN არ არის. სისტემურ proxy-დ მომუშავე კლიენტს ვერაფრის დაბლოკვა არ შეუძლია; აპლიკაციები, რომლებიც proxy-ს უგულებელყოფენ, პირდაპირ მიდიან, მუშაობს კლიენტი თუ არა. Kill switch-ისთვის კლიენტის VPN ან TUN რეჟიმი გჭირდება.
- Kill switch შეიძლება კლიენტზე მეტხანს დარჩეს. Firewall-ის წესები, რომლებიც tunnel-ის გარეთ ტრაფიკს ბლოკავს, ზოგჯერ ჩავარდნის შემდეგ ადგილზე რჩება და ინტერნეტის გარეშე გტოვებს. ეს გადამრთველი თავის საქმეს აკეთებს; კლიენტის რესტარტი ან მისი დოკუმენტირებული reset ამას ასუფთავებს.
უფრო საიმედო, ხელით აწყობილი ვარიანტია Windows Defender Firewall: გამავალი ტრაფიკის ნაგულისხმევი აკრძალვა, შემდეგ VPN კლიენტის კავშირის დაშვება სერვერის მისამართსა და პორტზე და ყველაფრის დაშვება VPN ადაპტერზე. ეს მუშაობს, კლიენტის ჩავარდნას უძლებს და მისით თავის გარეთ ჩაკეტვა ადვილია, ასე რომ სცადე მანქანაზე, რომელთანაც ფიზიკური წვდომა გაქვს.
macOS და iOS#
macOS-საც არ აქვს სისტემური kill switch. ზოგი კლიენტი მას macOS-ის პაკეტების ფილტრით (pf) ახორციელებს; ბევრი უბრალოდ არა. იგივე proxy-სა და VPN-ს შორის განსხვავება მოქმედებს: სისტემურ proxy-დ მომუშავე კლიენტი მხოლოდ იმ აპლიკაციებს იცავს, რომლებიც proxy-ს პატივს სცემენ.
iOS VPN აპებს აძლევს on-demand წესებს, რომლებიც VPN-ს ავტომატურად აერთებს, როცა მოწყობილობა ქსელს უერთდება, და უფრო ახალ პარამეტრს, რომელიც, როცა აპი მას იყენებს, მთელ ტრაფიკს tunnel-ში უნდა ატარებდეს და ბლოკავდეს, როცა tunnel გათიშულია. იყენებს თუ არა ამას კონკრეტული VPN აპი, მისი დეველოპერის გადასაწყვეტია, ასე რომ აპის საკუთარ პარამეტრებში მოძებნე on-demand ან ავტომატური მიერთების ოფციები. iOS-ის დიდი ხნის პრობლემაა, რომ კავშირები, რომლებიც VPN-ის ჩართვისას უკვე ღიაა, შეიძლება tunnel-ის გარეთ დარჩეს, სანამ არ დაიხურება; მიერთების შემდეგ airplane mode-ის მოკლედ ჩართვა-გამორთვა მათი გადატვირთვის უხეში გზაა.
Linux: წესი თავად დაწერე#
Linux-ზე ყველაზე სუფთა kill switch არის firewall-ის წესი, რომელიც ტრაფიკს გარეთ მხოლოდ tunnel-ის ინტერფეისით, თავად VPN სერვერამდე და ლოკალურ ქსელში უშვებს. nftables-ით:
table inet killswitch { chain output { type filter hook output priority 0; policy drop; oifname "lo" accept oifname "tun0" accept ip daddr 203.0.113.10 tcp dport 443 accept ip daddr 192.168.0.0/16 accept udp dport 67 accept }}ჩაანაცვლე tun0 შენი tunnel-ის ინტერფეისის სახელით (wg0 WireGuard-ისთვის, ან როგორც შენი Xray კლიენტი თავის TUN მოწყობილობას ეძახის), 203.0.113.10 და 443 შენი სერვერის მისამართითა და პორტით, ლოკალური დიაპაზონი კი შენით. DHCP-ის ხაზი lease-ის განახლებას უზრუნველყოფს. რადგან პოლიტიკა drop-ია, ყველაფერი, რაც ჩამოთვლილი არ არის, იბლოკება, მუშაობს VPN კლიენტი თუ არა - რაც მთელი აზრია, და ასევე მიზეზი, რის გამოც ის კონსოლიდან უნდა ჩატვირთო, რომელსაც მიწვდები, თუ რამე არასწორად წავა. პოსტი firewall-ის წესები, რომლებსაც მნიშვნელობა აქვს ნაგულისხმევი აკრძალვის წესებს უფრო ზოგადად განიხილავს.
როუტერები: ერთი kill switch მთელი ქსელისთვის#
ზოგ მოწყობილობას VPN კლიენტის გაშვება საერთოდ არ შეუძლია: ჭკვიანი ტელევიზორები აპების მაღაზიის გარეშე, სათამაშო კონსოლები, ძველი სტრიმინგ-მოწყობილობები. მათთვის VPN-ის გავლის ერთადერთი გზაა როუტერი, რომელიც კლიენტს უშვებს და მათ ტრაფიკს tunnel-ში აგზავნის. როუტერის firmware-ს, როგორიცაა OpenWrt, ამის გაკეთება შეუძლია, და community პაკეტები მას Xray-სა და sing-box-ს მატებს WireGuard-თან და OpenVPN-თან ერთად.
როუტერზე kill switch firewall-ის გადაწყვეტილებაა და არა აპის პარამეტრი. ჩვეულებრივი პატერნია tunnel-ის ინტერფეისის ცალკე firewall ზონაში მოთავსება და ლოკალური ქსელიდან forwarding-ის დაშვება მხოლოდ ამ ზონაში და არა ჩვეულებრივ, ინტერნეტისკენ მიმართულში. თუ tunnel გაითიშება, ლოკალურ მოწყობილობებს გადასაგზავნი არსად აქვთ და მათი ტრაფიკი ჩერდება, რაც kill switch-ია. თავად როუტერის ტრაფიკი, მაგალითად თავად VPN კავშირი და დროის სინქრონიზაცია, ისევ ჩვეულებრივი გზით გადის.
ორი გაფრთხილება. როუტერის kill switch მის უკან მყოფ ყველა მოწყობილობაზე მოქმედებს, ასე რომ, როცა VPN გათიშულია, მთელი სახლი ოფლაინაა და არა ერთი ტელეფონი. და როუტერის CPU ხშირად ქსელში ყველაზე ნელი პროცესორია; დაშიფვრამ, რომელსაც ტელეფონი შეუმჩნევლად აკეთებს, იაფი როუტერი შეიძლება ხაზის სიჩქარის მცირე ნაწილზე შეზღუდოს. რატომ არის ჩემი VPN ნელი შეიცავს ნიშნებს, რომლებსაც უნდა მიაქციო ყურადღება.
შუალედური გზა, რომელსაც ბევრი ოჯახი იყენებს: როუტერი tunnel-ში მხოლოდ იმ მოწყობილობებს ატარებს, რომლებსაც კლიენტის გაშვება არ შეუძლიათ, ტელეფონები და ლეპტოპები კი საკუთარ კლიენტს უშვებენ საკუთარი always-on პარამეტრებით.
Kill switch-ის ტესტირება#
მონიშნულ checkbox-ს რწმენით ნუ მიიღებ. გატესტე ის მომენტები, როცა გაჟონვები ხდება. ლეპტოპზე ციკლი, რომელიც ყოველ წამს შენს საჯარო მისამართს ბეჭდავს, ხარვეზებს თვალსაჩინოს ხდის:
$ while true; do curl -s --max-time 3 https://ifconfig.me; echo; sleep 1; done- მიუერთდი VPN-ს და გაუშვი ციკლი, ან გახსნილი დატოვე გვერდი, რომელიც შენს საჯარო მისამართს აჩვენებს, და განაახლე.
- ჩააგდე tunnel. ნებისმიერი მათგანი: მოკალი VPN კლიენტის პროცესი, დაბლოკე სერვერის მისამართი როუტერზე, wifi-დან მობილურ ინტერნეტზე გადადი, ან მოწყობილობა ძილის რეჟიმში გადაიყვანე და გააღვიძე.
- უყურე გამოსავალს. მომუშავე kill switch-ით ხედავ სერვერის მისამართს, შემდეგ timeout-ებს, სანამ tunnel გათიშულია, შემდეგ ისევ სერვერის მისამართს. მის გარეშე ხარვეზში შენი რეალური მისამართი ჩნდება.
- გაიმეორე ჩართვისას: გადატვირთე მოწყობილობა და შეამოწმე, რას აკეთებს პირველი მოთხოვნები, იდეალურად firewall-ის ან DNS-ის ლოგით შენს როუტერზე.
Android-ზე ტესტი უფრო მარტივია: ჩართული lockdown-ით გააჩერე VPN შეტყობინებიდან და სცადე ნებისმიერი გვერდის ჩატვირთვა. ის უნდა ჩავარდეს.
DNS გაჟონვის ტესტირების სახელმძღვანელო მუდმივ გაჟონვებს განიხილავს; ეს ტესტი გარდამავალს ფარავს. ორივე სუფთა გინდა.
კომპრომისები#
Kill switch VPN-ს შეგნებულად აქცევს მარცხის ერთ წერტილად. როცა სერვერი მიუწვდომელია, ინტერნეტი არ გაქვს. მისაღებია თუ არა ეს, დამოკიდებულია იმაზე, რატომ იყენებ VPN-ს.
- არასანდო ქსელებზე, ან სადაც ქსელი ტრაფიკს ბლოკავს ან აკვირდება, დახურვით ჩავარდნა სწორედ ისაა, რაც გინდა. რამდენიმე წუთი კავშირის გარეშე სჯობს რამდენიმე წუთს, როცა ყველაფერი ღიაა.
- სახლში, პროვაიდერისგან ჩვეულებრივი კონფიდენციალურობისთვის, always-on ბლოკის გარეშე გონივრული შუალედია: VPN თავისით ბრუნდება, მოკლე ხარვეზი კი კავშირს არ გიწყვეტს.
- ლოკალური მოწყობილობებისთვის შეამოწმე, რომ წესი შენს ლოკალურ ქსელს უშვებს, თორემ პრინტერი, NAS და casting მუშაობას წყვეტს, როცა VPN გათიშულია.
რაც არ უნდა აირჩიო, ეს ანონიმურობა არ არის. Kill switch მხოლოდ იმას იძლევა გარანტიას, რომ ტრაფიკი tunnel-ის გარეთ არ გადის; ის არ ცვლის, ვის შეუძლია მისი დანახვა შორეულ ბოლოში. VPN-ის გამოყენება ზოგ ქვეყანაში ასევე შეზღუდულია; იცოდე წესები იქ, სადაც ხარ.
პირადი VPN სერვერით#
RE:NODE-ის პირად VPN ხაზზე სერვერზე Xray მუშაობს VLESS-ითა და Reality-ით, საკუთარი მისამართითა და გასაღებით და ისე, რომ მასზე სხვა არავინაა. გაჟონვისგან დაცვა კლიენტის მხარის საქმეა, ასე რომ ის მოწყობილობიდან მოდის: Android-ზე v2rayNG ან Hiddify VPN რეჟიმში გადაიყვანე და ჩართე Always-on VPN ბლოკით; iPhone-ზე გამოიყენე კლიენტის ავტომატური მიერთების ოფციები; Windows-ზე Renode VPN აპი იმ ბმულით უერთდება, რომელსაც სერვერი ბეჭდავს, ხოლო ზემოთ აღწერილი firewall-ის მიდგომა, თუ გინდა, დახურვით ჩავარდნის ფენას ამატებს. ეს ერთი სერვერია ერთ ლოკაციაში, გერმანიაში, ასე რომ, როცა ის მიუწვდომელია - შენი ქსელი მის მისამართს ბლოკავს, სერვერი რესტარტდება, გზა გათიშულია - kill switch ზუსტად იმას გააკეთებს, რასაც ამბობს, და შენს ტრაფიკს შეაკავებს, სანამ ის არ დაბრუნდება. კლიენტის დაყენების სახელმძღვანელო ბმულის იმპორტს თითოეულ აპში განიხილავს.
FAQ#
რა განსხვავებაა kill switch-სა და always-on-ს შორის?
Always-on უზრუნველყოფს, რომ VPN მუშაობდეს - ის ჩართვისას ირთვება და გათიშვების შემდეგ ხელახლა უერთდება. Kill switch უზრუნველყოფს, რომ არაფერი გავიდეს, როცა ის არ მუშაობს - ხარვეზების დროს ტრაფიკი იბლოკება. ორივე გინდა: always-on ხარვეზების შესამცირებლად, kill switch მათ დასახურად.
რატომ არ მაქვს ინტერნეტი მას შემდეგ, რაც VPN აპი ჩავარდა?
Kill switch ისევ ბლოკავს ტრაფიკს tunnel-ის გარეთ, რისთვისაც ის არსებობს. გადატვირთე VPN კლიენტი და ის ან ხელახლა მიუერთდება, ან თავის წესებს მოხსნის. Android-ზე Block connections without VPN-ის გამორთვა წვდომას აღადგენს, თუ VPN ვერ უერთდება.
აჩერებს თუ არა Android-ის block connections without VPN ყველა გაჟონვას?
ის აპებს უშლის tunnel-ის გარეთ ტრაფიკის გაგზავნას, რაც ფარავს ჩართვას, ხელახლა მიერთებებსა და ჩავარდნებს. Android მაინც აგზავნის საკუთარი სისტემური ტრაფიკის ნაწილს, მაგალითად კავშირის შემოწმებებს, VPN-ის გარეთ. თითქმის ყველასთვის ეს მისაღებია; მკაცრი საფრთხის მოდელისთვის ღირს ამის ცოდნა.
შემიძლია kill switch-ის გამოყენება სასტუმროს wifi-ზე?
კი, მაგრამ ჯერ შესვლის გვერდი უნდა გაიარო, kill switch კი მას ბლოკავს. გამორთე ბლოკი, გაიარე portal, მიუერთდი VPN-ს, შემდეგ ბლოკი ისევ ჩართე.
ანელებს თუ არა kill switch კავშირს?
არა. Firewall-ის წესები, რომლებსაც ის ამატებს, ოპერაციული სისტემისთვის შესაფასებლად ტრივიალურია. ერთადერთი ფასი ხელმისაწვდომობაა: როცა VPN გათიშულია, შენი კავშირიც გათიშულია.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.