რატომ წყვეტს kill switch ტრაფიკს სერვერის შეცვლისას
რატომ ბლოკავს kill switch ტრაფიკს სერვერის შეცვლის დროს, რას აკეთებს კლიენტი ამ ფანჯარაში და როგორ განვასხვავოთ ნორმალური პაუზა ჩარჩენილი ბლოკისგან.
თქვენ ირჩევთ უფრო ახლოს მდებარე სერვერს, აჭერთ დაკავშირებას და ბრაუზერი წყვეტს ჩატვირთვას სანამ ახალი გვირაბი ამოქმედდება. ხატულა გადადის დაკავშირების მდგომარეობაში და იქ რჩება მანამ, სანამ ყველა ჩანართს ვადა არ გაუვა. ეს პაუზა ჩვეულებრივ kill switch-ის დაგეგმილი მუშაობაა: ტრაფიკი დაბლოკილია მანამ, სანამ კლიენტს არ აქვს გვირაბი მის გასაგზავნად. მისაღებია პაუზა თუ არა, დამოკიდებულია იმაზე, რას აკეთებს კლიენტი ამ წამებში და იმაზე, ხდება თუ არა ბლოკის მოხსნა მაშინ, როცა ის ამას ამბობს.
რას აკეთებს კლიენტი ორ სერვერს შორის
საბოლოო წერტილის შეცვლა რამდენიმე ნაბიჯია და არა ერთი გადამრთველი. კლიენტი შლის მიმდინარე გვირაბს, აახლებს თავის ბლოკირების წესებს, წყვეტს და აღწევს ახალ საბოლოო წერტილს გვირაბის გარეთ, შემდეგ აყენებს ახალ მარშრუტებს და ხსნის ბლოკს. შუალედი, რომელსაც გრძნობთ, პირველ და ბოლო ნაბიჯს შორისაა.
აქ რიგითობა უფრო მნიშვნელოვანია, ვიდრე სიჩქარე. თუ ბლოკირების წესები ახალი საბოლოო წერტილის გამონაკლისამდე ამოქმედდება, კლიენტი ვერ დაასრულებს ხელის ჩამორთმევას და დარჩება დაკავშირების მდგომარეობაში ვადის გასვლამდე. თუ გამონაკლისი ძველი სერვერის მისამართის ასლია, ახალი ხელის ჩამორთმევა ჩვეულებრივი გამავალი პაკეტივით გამოიყურება და უგულებელყოფილია. ორივე შემთხვევა ბრაუზერიდან ერთნაირად ჩანს, ამიტომ ექვსი წამის შემდეგ აღდგენილი და არასდროს აღდგენილი გადართვა შეიძლება ერთი და იმავე მიზეზის მქონე იყოს.
ახალ საბოლოო წერტილს ბლოკში ხვრელი სჭირდება
გვირაბის ასაგებად კლიენტმა პაკეტები უნდა გაგზავნოს ახალი სერვერის მისამართსა და პორტზე ფიზიკური ინტერფეისით, მაგალითად UDP 51820 ჩვეულებრივი WireGuard პროფილისთვის ან 1194 და 443 OpenVPN-ისთვის, რაც თქვენი პროფილი მიუთითებს. ეს ტრაფიკი არ არის იმ გვირაბის შიგნით, რომელიც ახლა იქმნება, ამიტომ მთელი მოწყობილობის ბლოკი მას შთანთქავს, თუ შესაბამისი ნებართვის წესი არ არსებობს.
ჰოსტის სახელზე დაფუძნებული პროფილები მეორე პირობას ამატებენ: თავად ძიებას. თუ კლიენტი საბოლოო წერტილს ბლოკის აწევამდე წყვეტს, შეუძლია ქეშირებული მისამართი გამოიყენოს, მაგრამ როცა პროფილი მისამართებს ცვლის ან ქეშის ჩანაწერი ძველდება, ხელის ჩამორთმევა მიდის მისამართზე, რომელსაც ნებართვის წესი არ ფარავს. IPv6 ამას თვალსაჩინოს ხდის, რადგან ორმაგი დასტის საბოლოო წერტილს შეუძლია გამოაქვეყნოს როგორც A, ისე AAAA ჩანაწერი, და მხოლოდ v4 მისამართის დამფარავი ნებართვის წესი კლიენტს ბლოკირებული v6 მისამართის წინააღმდეგ ხელახლა ცდაზე ტოვებს.
ოპციების სახელები და ნაგულისხმევი მნიშვნელობები კლიენტისა და ვერსიის მიხედვით განსხვავდება, ამიტომ წაიკითხეთ თქვენთვის განკუთვნილი დოკუმენტირებული სია და ნუ გამოიცნობთ ეკრანის სურათებიდან. OpenVPN Connect-ის პარამეტრების ცნობარი openvpn.net/connect-docs/app-settings-windows მისამართზე ერთი მაგალითია იმისა, თუ როგორ აღწერს კლიენტი თავის ბლოკისა და გაყოფილი გვირაბის ოპციებს.
Fail-closed მდგომარეობათა მანქანაა და არა გადამრთველი
კლიენტების უმეტესობა ბლოკს ხანძარსაწინააღმდეგო პოლიტიკად სამ მდგომარეობაში გამოხატავს: გვირაბი აწეულია, ტრაფიკი გვირაბში მიდის და ბლოკი არ არის; გვირაბი ჩამოშვებულია, ბლოკი აქტიურია; და გადასვლა, როცა ბლოკი აქტიურია პლუს დროებითი გამონაკლისები საბოლოო წერტილისთვის. სწორედ მესამე მდგომარეობაში ცხოვრობენ ხარვეზები, რადგან მან რამდენიმე წამში ორჯერ უნდა იცვალოს და მისგან გამოსვლის შეუძლებლობა ზუსტად მუდმივ ბლოკს ჰგავს.
მექანიზმი პლატფორმის მიხედვით განსხვავდება და წარუმატებლობაც. Windows Filtering Platform-ის ფილტრებს წონა აქვთ, ამიტომ თქვენს ნებართვას გადამეტებული ბლოკის ფილტრი პაკეტებს კვლავ აგდებს, თუმცა ნებართვა არსებობს, და მოკლული კლიენტის პროცესის მიერ დატოვებული ფილტრები შეიძლება მოწყობილობა ოფლაინში შეინარჩუნოს მას შემდეგ, რაც აპლიკაცია გაქრა. macOS-ის კლიენტები ჩვეულებრივ pf წესებს ანკერში წერენ, სადაც წესების რიგი და სწრაფი გადაწყვეტილებები განსაზღვრავს, რომელი წესი მოქმედებს. Linux-ის კლიენტები ჩვეულებრივ მართავენ nftables ან iptables ჯაჭვს drop პოლიტიკით და მკაფიო ნებართვებით საბოლოო წერტილისთვის, გვირაბის ინტერფეისისთვის და loopback-ისთვის. Android-ის always-on VPN, VPN-ის გარეშე კავშირების დაბლოკვის ოპციით, ჯგუფში ყველაზე მკაცრია, რადგან ოპერაციული სისტემა ბლოკს მთელ მოწყობილობაზე ავრცელებს და არა აპლიკაციაზე.
WireGuard-ს საკუთარი შენიშვნა სჭირდება, რადგან AllowedIPs მარშრუტის ამომრჩევია და არა ბლოკერი. ის განსაზღვრავს, რომელი დანიშნულებები შედის გვირაბში; ის არაფერს აკეთებს იმისთვის, რომ გვირაბის არმქონე პაკეტი Wi-Fi-ით არ გავიდეს. მხოლოდ WireGuard-ის და ხანძარსაწინააღმდეგო წესის გარეშე გამართულ სისტემაში kill switch რეალურად მარშრუტის არარსებობაა და უგულებელყოფილი ხელის ჩამორთმევის შემდეგ ფიზიკური ინტერფეისით რეალური პაკეტი შეიძლება გავიდეს.
გაზომეთ შუალედი და ნუ უყურებთ ხატულას
თვალყური ადევნეთ პაკეტებს და არა მდგომარეობის ნათებას. Linux-ში ერთ ტერმინალში დაიწყეთ ნელი ping საჯარო მისამართზე და მეორეში დაიჭირეთ გვირაბის ტრანსპორტის პორტი ფიზიკურ ინტერფეისზე:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
შეცვალეთ სერვერი კლიენტში, სანამ ორივე მუშაობს. სამი რამ არის მნიშვნელოვანი: რამდენ ხანს ჩერდება ping-ები, აჩვენებს თუ არა ჩაწერა ხელის ჩამორთმევის ახალ საბოლოო წერტილამდე მისვლას და ბრუნდება თუ არა ტრაფიკი მანამდე თუ მას შემდეგ, რაც კლიენტის მდგომარეობა დაკავშირებულად იცვლება. თუ ping-ის შუალედი პირველი მთავრდება, ან ბლოკი ნაადრევად მოიხსნა, ან გვირაბი ზევითაა სანამ ინდიკატორი ამას აღიარებს. თუ შუალედი უფრო გვიან მთავრდება, ინდიკატორი ზედმეტად ოპტიმისტურია.
Windows-ში netsh wfp show state წერს მომენტის სურათს, რომელშიც შეგიძლიათ მოძებნოთ ბლოკის ფილტრები, რომლებიც ჯერ კიდევ არსებობს, მაშინ როცა კლიენტი ამბობს, რომ გათიშულია. macOS-ში sudo pfctl -sr ჩამოთვლის ჩატვირთულ წესებსა და მათ რიგს. დააკავშირეთ ნებისმიერი სურათი კლიენტის საკუთარ ჟურნალს; თქვენი ping-ის დროითი ხაზი გეტყვით, დასრულდა ბლოკი გვიან თუ არასდროს.
ნორმალური დაბნელება ჩარჩენილი ბლოკის წინააღმდეგ
გარკვეული შეწყვეტა ამ ფუნქციის მიზანია, ამიტომ ნებისმიერი პარამეტრის შეცვლამდე გააკეთეთ კლასიფიკაცია:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
თუ მეორე ან მეხუთე რიგში მოხვდებით, ნუ გამორთავთ kill switch-ს შესამოწმებლად, რადგან ეს მარშრუტის ხარვეზს გაჟონვად აქცევს. გადატვირთეთ კლიენტის სერვისი ან გადატვირთეთ მოწყობილობა იქ, სადაც ფილტრები პროცესის მოკვლას გადაურჩება, შემდეგ ნახეთ, ქრება თუ არა ბლოკი. თუ ქრება, ხარვეზი გადართვის დროს გასუფთავებაშია და არა თავად ბლოკში.
შემდეგ გადართვამდე დაადასტურეთ ოთხი რამ: საბოლოო წერტილის ნებართვა ფარავს თქვენი პროფილის მიერ გადაწყვეტილ ყველა მისამართთა ოჯახს, კლიენტის ჟურნალი აჩვენებს დასრულებულ გადასვლას, თქვენი ping ტესტი ზომავს შუალედს და არა ხატულას, და კლიენტის დახურვა აღადგენს ნორმალურ კავშირს. kill switch, რომელიც გადართვის დროს ძლებს და შემდეგ უშვებს, თავის საქმეს აკეთებს. ის, რომელიც ნაადრევად ან არასდროს უშვებს, გამართვადია.