რატომ წყდება თქვენი VPN, როცა Wi-Fi იცვლება ან Ethernet ირთვება
'ახალი SSID, გადაადგილება წვდომის წერტილებს შორის და ჩართული კაბელი გვირაბს სამ სხვადასხვა ადგილას ამტვრევს. შეამოწმეთ წყაროს მისამართი, შემდეგ მარშრუტი, შემდეგ პროტოკოლი.'
ორი რამ ერთ ხარვეზად აღიწერება: ლეპტოპი სხვა Wi-Fi ქსელზე გადავიდა, ან კაბელი ჩაირთო, სანამ Wi-Fi ჩართული დარჩა. კლიენტი კვლავ ამბობს დაკავშირებულია, ხატულა ჯანსაღად გამოიყურება, და გვირაბი არაფერს გადააქვს. ზედაპირის ქვეშ მხოლოდ სამი მდგომარეობის ნაწილი შეიძლება გადაადგილდეს - კავშირი, ლოკალური მისამართი, ნაგულისხმევი მარშრუტი - და რომელი გადაადგილდა, ის წყვეტს გვირაბი თავად აღდგება თუ ხელახალი დაკავშირება სჭირდება. მე მათ ამ თანმიმდევრობით ვამოწმებ, რადგან ანგარიშის პარამეტრების შეცვლას არც ერთი მათგანი არ გაუსწორებია.
კავშირი, მისამართი და მარშრუტი დამოუკიდებლად მოძრაობენ
გადაადგილება ერთი ქსელის წვდომის წერტილებს შორის ჩვეულებრივ L2 მოვლენაა. რადიო ხელახლა უერთდება, ინტერფეისი ინარჩუნებს მისამართს და კარიბჭეს, და არაფერი, რაზეც გვირაბია დამოკიდებული, არ იცვლება, ამიტომ დიდ ოფისში სეირნობა ზოგჯერ შეუმჩნევლად გადის. სხვა SSID-ზე მიერთება ეს არ არის: ძველი ინტერფეისი შეიძლება ჩამოვარდეს, DHCP ახალ მისამართს, ახალ კარიბჭეს და ახალ გამხსნელებს აძლევს, და გარე ნაკადი, რომელსაც გვირაბი იყენებდა, წყვეტს არსებობას.
Ethernet მესამე ფორმას ამატებს. Wi-Fi არასდროს ვარდება, ამიტომ კავშირის მოვლენა საერთოდ არ ირთვება, მაგრამ მავთულის ინტერფეისი საკუთარი მისამართით ჩნდება და ხშირად იგებს ნაგულისხმევ მარშრუტს მეტრიკით. გვირაბი აგრძელებს მუშაობას გზაზე, რომელიც აღარ არის სასურველი, ან კლიენტი თავის სოკეტს ამაგრებს იმ უსადენო ქსელზე, რომელზეც დაიწყო. ბრაუზერიდან ორივე ერთნაირად გამოიყურება: გვერდები ჩერდება იმ წამს, როცა კაბელი ჯდება.
ასე რომ პირველი კითხვა არ არის, შეიცვალა თუ არა Wi-Fi. კითხვა ის არის, შეიცვალა თუ არა მისამართი, რომელზეც ხართ მიბმული, ან ბოლო წერტილამდე მიმავალი მარშრუტი, სანამ გვირაბი მუშაობდა.
გარე სოკეტი მიმაგრებულია მისამართზე, რომელიც ახლახან გაქრა
ყოველი გვირაბი გარე ნაკადია: ლოკალური მისამართი და პორტი ესაუბრება სერვერის მისამართსა და პორტს. Linux-ზე ეს არის UDP სოკეტი, მიბმული ძველ წყაროზე; როცა მისამართის მფლობელი ინტერფეისი იხსნება, გაგზავნები ან EADDRNOTAVAIL-ით მარცხდება, ან ახალი ინტერფეისიდან გადის წყაროთი, რომელიც სერვერს არასდროს უნახავს.
შორეული მხარე საკუთარ მიმაგრებას ინახავს. IKEv2 SA MOBIKE-ის გარეშე მისამართების წყვილით იდენტიფიცირდება, და OpenVPN სესია მიბმულია იმ თანამოძმის მისამართზე, რომელიც ისწავლა, და NAT ასახვა ეკუთვნის იმ კერძო მისამართს, პორტსა და საჯარო მისამართს, რომლებმაც ის შექმნეს. გადადით სხვა NAT-ის უკან და ყოველი პასუხი იგზავნება ასახვაზე, რომელიც აღარ არსებობს. თქვენს მანქანაზე არაფერია არასწორად კონფიგურირებული; ხუთეული მიუთითებს ქსელზე, რომელიც დატოვეთ.
წაიკითხეთ მდგომარეობა, სანამ თეორიებს ააგებთ:
ss -unpგვიჩვენებს ლოკალურ მისამართსა და პორტს, რომელსაც ყოველი გვირაბის სოკეტი რეალურად ფლობს.ip route get 203.0.113.10ბეჭდავს წყაროს მისამართსა და მოწყობილობას, რომელსაც ბირთვი ახლა გამოიყენებდა ბოლო წერტილისთვის.wg show wg0 endpoints,swanctl --list-sasან კლიენტის ჟურნალი გვიჩვენებს თანამოძმის მისამართს, რომელთანაც შორეული მხარე ფიქრობს, რომ საუბრობს.
თუ სოკეტის მისამართი და მარშრუტის ძებნა არ თანხვდება, თქვენ იპოვეთ წყვეტა, და ვერც ერთი სერტიფიკატის ცვლილება ვერ შეეხება მას.
რას აკეთებს ყოველი პროტოკოლი ახალი წყაროს მისამართით
კლიენტები ცვლილებას სხვადასხვა ხარისხით შთანთქავენ, და ცხრილი არის ის, რასაც კლიენტის კონფიგურაციას ვადარებ, ხელახალი დაკავშირების ქცევიდან გამოცნობის ნაცვლად.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard-ის გადაადგილების წესი მხოლოდ ერთი მიმართულებით მუშაობს: კლიენტმა ჯერ ახალი მისამართიდან უნდა გაგზავნოს. ძველ ინტერფეისზე კვლავ მიბმული სოკეტი ამას არასდროს აკეთებს, ამიტომ გვირაბი შეიძლება ცოცხლად გამოიყურებოდეს, სანამ მისი ხელის ჩამორთმევის ტაიმერი ბერდება. პროტოკოლის აღწერა ზუსტად აყალიბებს ბოლო წერტილის განახლების პირობას, და ღირს მისი წაკითხვა კონფიგურაციის შეცვლამდე.
MOBIKE მოლაპარაკებით წყდება, არ ვარაუდობენ. თუ სერვერი არ გვთავაზობს, კლიენტმა ხელახლა უნდა დაამყაროს, და ეს არის ფაქტი, რომელსაც SA სიიდან ან ჟურნალიდან ადასტურებთ, და არა მბრუნავი ბორბლიდან გამოიტანთ.
გზას მარშრუტის უპირატესობა წყვეტს, და არა Wi-Fi-ის ხატულა
ორივე ინტერფეისის ჩართულობისას ბირთვი მეტრიკითა და პრეფიქსის სიგრძით ირჩევს. ip route show default ჩამოთვლის კანდიდატებს და ip route get 203.0.113.10 წყვეტს ნამდვილ გადაწყვეტილებას, წყაროს მისამართის ჩათვლით. მავთულის ნაგულისხმევი 100 მეტრიკით და უსადენო 600-ით ნიშნავს, რომ ბოლო წერტილი მოძრაობს იმ წამს, როცა კაბელი ჯდება, მაშინ როცა ადრე გახსნილი სოკეტის მქონე ყოველი პროგრამა თავის ძველ წყაროს ინახავს.
Windows იგივეს აკეთებს ავტომატური ინტერფეისის მეტრიკებით, კავშირის სიჩქარით მიკერძოებული. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ალაგებს კანდიდატებს და Find-NetRoute -RemoteIPAddress 203.0.113.10 აბრუნებს ინტერფეისსა და წყაროს, რომელსაც სტეკი აირჩევდა. კლიენტი, რომელიც თავის გარე სოკეტს ერთ ინტერფეისზე აბამს, აგრძელებს მის გამოყენებას მეტრიკის გადატრიალების შემდეგაც; ეს მიბმის გადაწყვეტილებაა, და არა მარშრუტიზაციის ხარვეზი.
Android ყოფს ხილულს: ConnectivityManager იუწყება ხელმისაწვდომ ქსელებს და ცალკე ნაგულისხმევს, და VPN პროგრამა, რომელიც სოკეტს Network ობიექტზე აბამს, ინახავს ამ მიბმას სანამ ხელახლა არ აბამს. macOS-ზე scutil --nwi ბეჭდავს ძირითად ინტერფეისს და იმ რიგს, რომელსაც სისტემა გამოიყენებდა.
DNS, MTU და IPv6 კავშირთან ერთად მოძრაობენ
ახალი კავშირი ახალ გამხსნელებს მოაქვს. systemd-resolved-ით DNS კავშირზეა დამოკიდებული, resolvectl status გვიჩვენებს, რომელი კავშირი პასუხობს სახელს, და სტუმრის ქსელი, რომელიც საკუთარ გამხსნელს აძლევს, შეიძლება გვირაბის მიერ გაგზავნილი DNS გამოუყენებელი დატოვოს, სანამ კავშირი კვლავ სასურველი გახდება. დამჭერი პორტალი ამძიმებს: პირველ HTTPS მოთხოვნას პორტალი პასუხობს და არა ბოლო წერტილი, და კლიენტი მკვდარ სერვერს აფიქსირებს.
გზის MTU-ც იცვლება. Ethernet და Wi-Fi ჩვეულებრივ 1500 ბაიტს ატარებს, PPPoE 1492-ს, ხოლო მობილური კავშირები ხშირად ნაკლებს. გვირაბი, რომელიც უფრო პატარა MTU-ს მემკვიდრეობით იღებს, დიდ პაკეტებზე ჩერდება, მაშინ როცა პატარა მოთხოვნები გადის, რაც ნახევრად გატეხილ კავშირად იკითხება. ping -M do -s 1472 203.0.113.10 1500 ბაიტიან პაკეტს აგზავნის DF-ით; სიჩუმე ნიშნავს, რომ გზა უფრო პატარაა, ვიდრე ვარაუდობდით.
IPv6 მეორე ნახევარია. ქსელი, რომელიც ახალ პრეფიქსს აძლევს, ცვლის წყაროს, რომელსაც ორსტეკიანი კლიენტი გამოიყენებდა, და მხოლოდ v4 გვირაბი v6 ტრაფიკს გარეთ ტოვებს, სანამ პოლიტიკა დაეწევა. ip -6 route show default და ip -6 addr show პასუხობენ, აქვს თუ არა ახალ კავშირს საერთოდ v6 გზა.
აღწერის ნაცვლად გადასვლა გაამეორეთ
აირჩიეთ ერთი უვნებელი მოთხოვნა და გაუშვით იგივე სამი ბრძანება ცვლილების ორივე მხარეს: ip -br addr, ip route show default, ip route get 203.0.113.10. შემდეგ დააკვირდით, კვლავ აგზავნის თუ არა გვირაბი პაკეტებს - tcpdump -ni any udp port 51820 WireGuard-ისთვის, შესაბამისი პორტი ყველაფერ სხვასთვის. ძველი წყაროდან გამავალი პაკეტები მიბმის პრობლემას ნიშნავს. ახალი წყაროდან უპასუხოდ გამავალი პაკეტები შორეულ მხარეს ან შუალედურ NAT-ს ნიშნავს.
ჩაიწერეთ, რომელი მოვლენა დაემთხვა პირველ ხარვეზს: კავშირის ჩავარდნა, მისამართის ცვლილება ან ნაგულისხმევი მარშრუტის ცვლილება. ეს სხვადასხვა პასუხისმგებელზე მიუთითებს - კლიენტი, რომელიც ხელახლა უნდა იყოს მიბმული, მისამართი, რომელიც ხელახლა უნდა მოიპოვოს, ან მარშრუტი, რომელიც კონფიგურაციის ფაილს ეკუთვნის და არა მუდმივ გვერდის ავლის წესს.
სანამ გამოსწორებულს უწოდებთ, დაადასტურეთ, რომ პირდაპირი ტრაფიკის ბლოკი უფსკრულის განმავლობაშიც ძლებს და სახელები ახალი კავშირით იხსნება. თუ კლიენტი გადართვის შემდეგ ძველ ბოლო წერტილს ინახავს, ჯერ გადაადგილების ან float-ის პარამეტრი გაასწორეთ. თუ სწორად გადაადგილდება და მაინც პასუხს არ იღებს, შეხედეთ სერვერის თანამოძმის იდენტობას და გზის NAT-ს, და ორივე ქსელური კონტექსტი ჩანაწერში შეინახეთ, რომ შემდეგმა ადამიანმა შეძლოს მათი შედარება.