Kill switch VPN სერვერს ბლოკავს ნებისმიერი ტრაფიკის გადინებამდე
რომელ საფეხურს ბლოკავს kill switch: საბოლოო წერტილის ძიება, გარე მარშრუტი, დაბრუნების გზა და მოძველებული პარტნიორის გამონაკლისები — ვარაუდების ნაცვლად მთვლელებით.
Kill switch-ები იმ მიმართულებით ცდება, რომელსაც ადამიანები არ ელოდებიან: ისინი იმისთვისაა აგებული, რომ ტრაფიკი დაბლოკონ, სანამ გვირაბი გამორთულია, და გვირაბის მშენებელი პაკეტები თავად ტრაფიკია. მთელი შეცდომა ეს არის. წესების ნაკრები, რომელიც ყრის ყველაფერს, რაც გვირაბიდან არ გადის, ყრის იმ ხელის ჩამორთმევასაც, რომელმაც ის უნდა ასწიოს, ამიტომ კლიენტი ციკლში ხელახლა ცდილობს და შეცდომა იმ საფეხურს მიეწერება, რომელიც პირველად მოწმდება. ფაირვოლის გაფართოებამდე გაარკვიეთ, სამი საფეხურიდან რომელი უარყოფილია: სახელის ძიება, გარე პაკეტი პარტნიორისკენ, თუ უკან დაბრუნებული პასუხი.
როგორ არიან გვირაბი და მისი საკუთარი ტრანსპორტი ერთმანეთზე დამოკიდებული
წაიკითხეთ VPN კლიენტი როგორც ქსელის ორი მდგომარეობა, რომლებიც ერთ სოკეტის გზას იზიარებენ. სანამ გვირაბი არსებობს, კლიენტი ფიზიკურ ადაპტერზე სოკეტს ხსნის და დაშიფრულ ჩარჩოებს პარტნიორის მისამართსა და პორტზე აგზავნის. მხოლოდ ამ გაცვლის წარმატების შემდეგ ქმნის გვირაბის მოწყობილობას და ამონტაჟებს მარშრუტებს. Kill switch მეორე მდგომარეობის პოლიტიკაა, იმდენად ფართოდ დაწერილი, რომ ორივეზე ვრცელდება.
ინტერფეისზე დაფუძნებული წესები ჩვეულებრივი ფორმაა: მიიღეთ ის, რაც გადის tun0 ან wg0-ით, დარჩენილი გასასვლელი გზა გადაყარეთ. ეს ფორმულირება ვერ გამორიცხავს კლიენტის საკუთარ კავშირს სერვერთან, ამიტომ სწორი იმპლემენტაცია ამ გამონაკლისს ცალსახად ამატებს, და თქვენც, როცა წესებს ხელით წერთ. Windows-სა და macOS-ზე აპლიკაციაზე დაფუძნებული წესები ამის ნაწილს იცილებენ ინტერფეისის ნაცვლად პროცესის დამთხვევით, მაგრამ პროცესმა მაინც უნდა გავიდეს გარეთ, სანამ გვირაბი არსებობს.
სამი საფეხური, იმ თანმიმდევრობით, როგორც ხდება
პირველი საფეხური ამოხსნაა. როცა პროფილი პირდაპირი მისამართის ნაცვლად ჰოსტის სახელს ინახავს, კლიენტს არაფრის გაგზავნამდე DNS-ის პასუხი სჭირდება. პროფილი, რომელიც DNS-ს გვირაბის ამომხსნელისკენ მიმართავს, ჩიხს ქმნის: ამომხსნელი მისაწვდომია მხოლოდ იმ გვირაბით, რომელიც ძიებამ უნდა ჩართოს. გვირაბის გარეთ ამოხსნა, ან საბოლოო წერტილის მისამართზე მიმაგრება, ამ გაურკვევლობას აშორებს.
მეორე საფეხური გარე პაკეტია, რომელმაც ამ თანმიმდევრობით ჯერ მარშრუტიზაცია, შემდეგ ფაირვოლი უნდა გადაიტანოს. wireguard-tools WireGuard-ისთვის ამის მარშრუტიზაციის ნახევარს აკეთებს: საკუთარ პაკეტებს ნიშნავს და პოლიტიკის წესს ამატებს, რათა გადაუხვიონ ახლახან დაყენებულ ნაგულისხმევ მარშრუტს; wg-quick-ის სახელმძღვანელოს გვერდი აღწერს ამ წესს და ცხრილს, რომელსაც ის იყენებს. ხელახლა ააგეთ ეს მარშრუტიზაცია ხელით, ან მიეცით მეორე ხელსაწყოს წესების გადაწერის უფლება, და ნიშნიანი პაკეტები შეიძლება უკან, იმ გვირაბში გაიგზავნოს, რომელიც მათ უნდა შექმნან.
მესამე საფეხური დაბრუნების გზაა. პასუხის გარეშე ხელის ჩამორთმევა გარეთ გადაგდების მტკიცებულება არ არის; ის თანაბრად თანხვედრაშია სერვერის შემავალ წესთან ან NAT მოწყობილობასთან, რომელსაც დაკავშირება დაავიწყდა. გამოყავით ეს ერთმანეთისგან, სანამ კლიენტს შეეხებით.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
კლიენტები იწერენ იმ სიმპტომს, რომელსაც აღმოაჩენენ, და არა იმ საფეხურს, რომელიც ჩავარდა, ამიტომ ცხრილი ჩვეულებრივ ჟურნალზე სწრაფია.
მთვლელები ჟურნალებზე სწრაფად წყვეტენ
Linux-ზე, nft list ruleset ან iptables -vnL OUTPUT თითო წესზე პაკეტების მთვლელს ბეჭდავს. ერთხელ დაუკავშირდით, ჩავარდნის უფლება მიეცით, შემდეგ კვლავ წაიკითხეთ მთვლელები. წესი, რომლის მთვლელიც გადაადგილდა, ის წესია, რომელსაც ხელის ჩამორთმევა მოხვდა; თუ არსად არაფერი გადაადგილდა, პაკეტი ფაირვოლამდე არასდროს მივიდა. მინახავს წესების ნაკრები, რომელმაც საკუთარი ხელის ჩამორთმევა გადააგდო, და ეს მხოლოდ მთვლელებმა თქვეს.
იმის გასარჩევად, არასდროს მივიდა ფაირვოლამდე თუ არასდროს დატოვა ჰოსტი, თვალყური ადევნეთ თავად ინტერფეისს. ip -s link show dev wlan0 იტყობინება გაგზავნილ პაკეტებზე, და tcpdump -ni wlan0 udp port 51820 აჩვენებს ჩარჩოებს. თუ ის ბრტყელი რჩება, სანამ კლიენტი ხელახლა ცდილობს, ხარვეზი netfilter-ის ზემოთაა: დაკარგული პარტნიორის მარშრუტი, პოლიტიკის წესი, რომელიც ჯერ არარსებულ მოწყობილობაზე მიუთითებს, ან სოკეტის შეცდომა, რომელსაც კლიენტი ყლაპავს.
გამონაკლისები შეამოწმეთ დოკუმენტაციის მისამართებზე, მაგალითად 203.0.113.10, რათა შეცდომამ სხვისი ჰოსტი ვერ შეამოწმოს.
მოძველებული საბოლოო წერტილის გამონაკლისი სერვერის გათიშვად იკითხება
ყველაზე შემცდენი ვარიანტი მას შემდეგ ჩნდება, რაც პარტნიორის მისამართი იცვლება: დინამიკური მისამართების სერვისმა გადააადგილა, ჰოსტი ხელახლა აშენდა, ან თქვენი ქსელის გასასვლელი მისამართი სხვაა. გამონაკლისი კვლავ ძველ მისამართს ასახელებს, ამიტომ ახალზე მიმავალი პაკეტები გადაგდების წესზე ხვდება. იგივე კონფიგურაცია გუშინ მუშაობდა, და სწორედ ამიტომ იწყებენ ადამიანები სერვერის დიაგნოსტიკით.
ფაირვოლის წესში ჩასმული ჰოსტის სახელი ვერ გიხსნით. nftables-ში სახელი წესების ნაკრების ჩატვირთვისას ამოიხსნება, ამიტომ ის იმ მომენტში არსებულ მისამართს ამაგრებს და პირდაპირი მისამართივით ძველდება. გამძლე გადაწყვეტაა გამონაკლისის განახლება, როცა საბოლოო წერტილი იცვლება, და მისი ვიწროდ შენახვა: ერთი პარტნიორის მისამართი, ერთი ტრანსპორტის პორტი. დიაპაზონი, რომელიც საკმარისად ფართოა მისამართის ცვლილების გადასატანად, საკმარისად ფართოა უკავშირო ტრაფიკის გასაშვებადაც.
როცა kill switch სერვერის ჰოსტზე მუშაობს
იგივე დამოკიდებულება მეორე ბოლოშიც არსებობს, და იქ მისი გამოტოვება უფრო ადვილია. თუ მანქანა, რომელიც თქვენს VPN სერვერად მუშაობს, kill switch-იან სამუშაო მაგიდის კლიენტს ან ლეპტოპიდან დაკოპირებულ ფაირვოლის პროფილსაც უშვებს, მისი გადაგდების წესები გვირაბების დამამთავრებელ სერვისზე ვრცელდება. კლიენტის ხელის ჩამორთმევაზე პასუხები გადაგდება, ამიტომ ყოველი კლიენტი ვერ უკავშირდება, მაშინ როცა სერვერი ჯანმრთელად გამოიყურება და მისი გვირაბის ინტერფეისი გამოუყენებელი დგას.
ამ ჰოსტს გადაგდებამდე სამი ვიწრო მიღება სჭირდება: მოსმენის პორტი ფიზიკურ ინტერფეისზე, გვირაბის ინტერფეისი გაშიფრული ტრაფიკისთვის, და გადაცემა გვირაბიდან იქეთ, სადაც კლიენტებმა უნდა მიაღწიონ. წაიკითხეთ დაყენებული ნაკრები nft list ruleset, iptables -S, ან pfctl -sr -ით, სანამ რამეს შეცვლით, და გახსოვდეთ, რომ შენახული წესების ნაკრები გადატვირთვას გადაურჩება, ამიტომ იქაური შეცდომა მის შემქმნელ პროცესს გადაურჩება.
აღდგენის რიგი, რომელიც მანქანას დახურულად ინახავს
იმუშავეთ პროფილიდან გარეთ. წაიკითხეთ პარტნიორის მისამართი და პორტი, რომელსაც კლიენტი იყენებს, დაადასტურეთ, რომ ჰოსტის სახელი გვირაბის გარეშე იხსნება, შემდეგ დაამატეთ ერთი გამონაკლისი ამ მისამართისა და პორტისთვის მხოლოდ ფიზიკურ ადაპტერზე. ხელახლა დაუკავშირდით და დააკვირდით გაგზავნის მთვლელს; დასრულებული ხელის ჩამორთმევა ნიშანია, რომ მეორე საფეხური გამოსწორდა.
ტესტირებისას გადაგდების დარჩენილი პოლიტიკა ადგილზე დატოვეთ. უვნებელი შემოწმებაა უკავშირო დოკუმენტაციის მისამართზე კავშირის ცდა და დადასტურება, რომ ის კვლავ დროში იწურება, რაც აჩვენებს, რომ kill switch მუშაობს და არ არის გამორთული. გაამკაცრეთ გამონაკლისი, როცა გვირაბი სტაბილური გახდება, და ნუ დატოვებთ მუდმივ ყველაფრის ნებართვას კლიენტის პროგრამისთვის მხოლოდ იმიტომ, რომ მოსახერხებელია.
თუ გვირაბი ადის და აპლიკაცია მაინც ვარდება, დარჩენილი საფეხურები ეს არ არის: გაყოფილი DNS, MTU და თითო აპლიკაციის მარშრუტიზაცია თითოეული დაკავშირებულ გვირაბს ქმნის გატეხილი ტრაფიკით, და თითოეულს პირველი შემოწმება განსხვავებული აქვს.