ทำไม VPN ของคุณจึงหลุดเมื่อ Wi-Fi เปลี่ยนหรือเสียบ Ethernet
'SSID ใหม่ การโรมมิงระหว่างจุดเชื่อมต่อ และสายที่เสียบอยู่ ทำให้ทันเนลขาดในสามจุดที่ต่างกัน ตรวจสอบแอดเดรสต้นทาง จากนั้นเส้นทาง จากนั้นโปรโตคอล'
สองสิ่งถูกรายงานเป็นความล้มเหลวเดียว: แล็ปท็อปย้ายไปเครือข่าย Wi-Fi อื่น หรือมีสายเสียบเข้าในขณะที่ Wi-Fi ยังทำงานอยู่ ไคลเอนต์ยังบอกว่าเชื่อมต่ออยู่ ไอคอนดูปกติ และทันเนลไม่ส่งข้อมูลใดเลย ภายใต้พื้นผิว มีเพียงสามส่วนของสถานะที่ขยับได้ คือ ลิงก์ แอดเดรสภายใน และเส้นทางเริ่มต้น และส่วนที่ขยับคือสิ่งที่กำหนดว่าทันเนลจะฟื้นตัวเองหรือต้องเชื่อมต่อใหม่ ผมตรวจสอบตามลำดับนั้น เพราะการเปลี่ยนการตั้งค่าบัญชีไม่เคยแก้ไขสักส่วนเดียว
ลิงก์ แอดเดรส และเส้นทางขยับอย่างเป็นอิสระ
การโรมมิงระหว่างจุดเชื่อมต่อในเครือข่ายเดียวกันมักเป็นเหตุการณ์ระดับ L2 วิทยุเชื่อมต่อใหม่ อินเทอร์เฟซยังคงแอดเดรสและเกตเวย์ไว้ และไม่มีสิ่งที่ทันเนลพึ่งพาเปลี่ยนไป นั่นคือเหตุผลที่การเดินผ่านออฟฟิศใหญ่อาจผ่านไปโดยไม่รู้ตัว การเชื่อมต่อกับ SSID อื่นไม่ใช่เช่นนั้น: อินเทอร์เฟซเดิมอาจล่ม DHCP แจกแอดเดรสใหม่ เกตเวย์ใหม่ และตัวแปลงชื่อใหม่ และโฟลว์ภายนอกที่ทันเนลใช้อยู่ก็สิ้นสุดลง
Ethernet เพิ่มรูปแบบที่สาม Wi-Fi ไม่เคยหลุด จึงไม่มีเหตุการณ์ลิงก์เกิดขึ้นเลย แต่อินเทอร์เฟซแบบมีสายปรากฏขึ้นพร้อมแอดเดรสของตัวเองและมักชนะเส้นทางเริ่มต้นด้วยเมตริก ทันเนลยังเดินต่อบนเส้นทางที่ไม่ใช่ทางเลือกแรกแล้ว หรือไคลเอนต์ตรึงซ็อกเก็ตไว้กับเครือข่ายไร้สายที่เริ่มต้นไว้ จากเบราว์เซอร์ทั้งสองดูเหมือนกัน: หน้าเว็บหยุดทันทีที่สายเข้าที่
ดังนั้นคำถามแรกไม่ใช่ Wi-Fi เปลี่ยนหรือไม่ แต่คือแอดเดรสที่คุณผูกอยู่ หรือเส้นทางไปยังปลายทาง เปลี่ยนไปในขณะที่ทันเนลทำงานหรือไม่
ซ็อกเก็ตภายนอกถูกตรึงไว้กับแอดเดรสที่เพิ่งหายไป
ทุกทันเนลคือโฟลว์ภายนอก: แอดเดรสและพอร์ตภายในที่คุยกับแอดเดรสและพอร์ตของเซิร์ฟเวอร์ บน Linux นั่นคือซ็อกเก็ต UDP ที่ผูกกับต้นทางเดิม เมื่ออินเทอร์เฟซที่ถือแอดเดรสถูกลบ การส่งจะล้มเหลวด้วย EADDRNOTAVAIL หรือออกผ่านอินเทอร์เฟซใหม่ด้วยต้นทางที่เซิร์ฟเวอร์ไม่เคยเห็น
ฝั่งไกลเก็บการตรึงของตัวเอง SA ของ IKEv2 ที่ไม่มี 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 จะคงการผูกนั้นไว้จนกว่าจะผูกใหม่ บน macOSscutil --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 ตามเส้นทาง และเก็บบริบทเครือข่ายทั้งสองไว้ในบันทึกเพื่อให้คนต่อไปเทียบได้