Vì sao VPN của bạn rớt khi Wi-Fi đổi hoặc cắm Ethernet
SSID mới, chuyển vùng giữa các điểm truy cập và một sợi cáp vừa cắm phá vỡ đường hầm ở ba chỗ khác nhau. Kiểm tra địa chỉ nguồn, rồi tuyến đường, rồi giao thức.
Hai chuyện được báo cáo như một lỗi duy nhất: máy tính chuyển sang mạng Wi-Fi khác, hoặc cắm cáp trong khi Wi-Fi vẫn chạy. Ứng dụng vẫn nói đã kết nối, biểu tượng trông khỏe, và đường hầm không chở gì cả. Bên dưới, chỉ ba mẩu trạng thái có thể dịch chuyển - kết nối, địa chỉ cục bộ, tuyến mặc định - và mẩu nào dịch chuyển sẽ quyết định đường hầm tự phục hồi hay cần kết nối lại. Tôi kiểm tra chúng theo thứ tự đó, vì đổi thiết lập tài khoản chưa bao giờ sửa được mẩu nào.
Kết nối, địa chỉ và tuyến đường dịch chuyển độc lập
Chuyển vùng giữa các điểm truy cập trong cùng mạng thường là sự kiện L2. Radio liên kết lại, giao diện giữ nguyên địa chỉ và cổng, và không có gì đường hầm phụ thuộc vào bị đổi, nên đi bộ qua một văn phòng lớn đôi khi trôi qua mà không ai nhận ra. Gia nhập SSID khác thì không phải vậy: giao diện cũ có thể sập, DHCP cấp địa chỉ mới, cổng mới và bộ phân giải mới, và luồng ra ngoài mà đường hầm dùng không còn tồn tại.
Ethernet thêm dạng thứ ba. Wi-Fi không bao giờ sập, nên không có sự kiện kết nối nào được kích hoạt, nhưng giao diện có dây xuất hiện với địa chỉ riêng và thường thắng tuyến mặc định theo metric. Đường hầm tiếp tục chạy trên con đường không còn được ưu tiên, hoặc ứng dụng giữ socket gắn chặt vào mạng không dây mà nó bắt đầu. Từ trình duyệt, cả hai trông giống nhau: trang đứng lại đúng lúc cáp khớp.
Vậy câu hỏi đầu tiên không phải Wi-Fi có đổi không. Mà là địa chỉ bạn đang gắn vào, hoặc tuyến tới điểm cuối, có đổi trong lúc đường hầm đang chạy không.
Socket ngoài đang gắn vào một địa chỉ vừa biến mất
Mỗi đường hầm là một luồng ngoài: một địa chỉ và cổng cục bộ nói chuyện với địa chỉ và cổng của máy chủ. Trên Linux đó là socket UDP gắn với nguồn cũ; khi giao diện giữ địa chỉ bị gỡ, các lần gửi hoặc thất bại với EADDRNOTAVAIL hoặc đi ra qua giao diện mới với nguồn mà máy chủ chưa từng thấy.
Phía xa giữ chốt riêng của nó. Một SA IKEv2 không có MOBIKE được nhận diện bằng cặp địa chỉ, và một OpenVPN phiên gắn với địa chỉ đối tác mà nó đã học, và ánh xạ NAT thuộc về địa chỉ riêng, cổng và địa chỉ công cộng đã tạo ra nó. Chuyển ra sau một NAT khác và mọi phản hồi đi tới một ánh xạ không còn tồn tại. Không có gì trên máy bạn bị cấu hình sai; bộ năm chỉ vào một mạng bạn đã rời.
Đọc trạng thái trước khi lý thuyết hóa:
ss -unphiển thị địa chỉ và cổng cục bộ mà mỗi socket đường hầm thực sự giữ.ip route get 203.0.113.10in ra địa chỉ nguồn và thiết bị mà nhân sẽ dùng cho điểm cuối ngay lúc này.wg show wg0 endpoints,swanctl --list-sashoặc nhật ký ứng dụng hiển thị địa chỉ đối tác mà phía xa nghĩ là đang nói chuyện.
Nếu địa chỉ socket và tra cứu tuyến không khớp, bạn đã tìm ra chỗ đứt, và không thay đổi thông tin đăng nhập nào chạm tới nó.
Mỗi giao thức làm gì với một địa chỉ nguồn mới
Các ứng dụng hấp thụ thay đổi ở mức khác nhau, và bảng này là thứ tôi đối chiếu với cấu hình ứng dụng thay vì đoán từ hành vi kết nối lại.
| 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. |
Quy tắc chuyển vùng của WireGuard chỉ chạy một chiều: ứng dụng phải gửi từ địa chỉ mới trước. Một socket còn gắn với giao diện cũ không bao giờ làm vậy, nên đường hầm có thể trông còn sống trong khi bộ đếm bắt tay của nó già đi. mô tả giao thức nêu chính xác điều kiện cập nhật điểm cuối, và đáng đọc trước khi đổi cấu hình.
MOBIKE được thương lượng, không được giả định. Nếu máy chủ không cung cấp, ứng dụng phải thiết lập lại, và đó là sự thật bạn xác nhận từ danh sách SA hoặc nhật ký, chứ không phải suy ra từ một bánh xe đang quay.
Ưu tiên tuyến quyết định đường đi, không phải biểu tượng Wi-Fi
Khi cả hai giao diện đều bật, nhân chọn theo metric và độ dài tiền tố. ip route show default liệt kê các ứng viên và ip route get 203.0.113.10 giải quyết quyết định thật, gồm cả địa chỉ nguồn. Một tuyến mặc định có dây metric 100 và một tuyến không dây metric 600 nghĩa là điểm cuối dịch chuyển đúng lúc cáp vào, trong khi mọi ứng dụng đã mở socket trước đó vẫn giữ nguồn cũ.
Windows làm điều tương tự với metric giao diện tự động, bị lệch theo tốc độ liên kết. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sắp xếp các ứng viên và Find-NetRoute -RemoteIPAddress 203.0.113.10 trả về giao diện và nguồn mà ngăn xếp sẽ chọn. Ứng dụng gắn socket ngoài vào một giao diện thì tiếp tục dùng nó sau khi metric đảo; đó là quyết định gắn, không phải lỗi định tuyến.
Android làm phần tách hiện rõ: ConnectivityManager báo các mạng khả dụng và một mặc định riêng, và ứng dụng VPN gắn socket vào một đối tượng Network giữ mối gắn đó cho tới khi gắn lại. Trên macOS, scutil --nwi in ra giao diện chính và thứ tự mà hệ thống sẽ dùng.
DNS, MTU và IPv6 dịch chuyển theo kết nối
Kết nối mới mang theo bộ phân giải mới. Với systemd-resolved, DNS là theo từng liên kết, resolvectl status cho biết liên kết nào trả lời một cái tên, và một mạng khách phát bộ phân giải riêng có thể để DNS do đường hầm đẩy vào không được dùng cho tới khi liên kết lại được ưu tiên. Cổng chặn càng làm tệ hơn: yêu cầu HTTPS đầu tiên được cổng trả lời thay cho điểm cuối, và ứng dụng ghi nhận một máy chủ đã chết.
MTU của đường đi cũng đổi. Ethernet và Wi-Fi thường chở 1500 byte, PPPoE 1492, và liên kết di động thường ít hơn. Một đường hầm thừa hưởng MTU nhỏ hơn sẽ tắc ở gói lớn trong khi yêu cầu nhỏ vẫn qua, và điều đó đọc ra như một kết nối hỏng một nửa. ping -M do -s 1472 203.0.113.10 gửi một gói 1500 byte với DF được bật; im lặng nghĩa là đường đi nhỏ hơn bạn giả định.
IPv6 là nửa còn lại. Một mạng phát tiền tố mới sẽ đổi nguồn mà ứng dụng hai ngăn xếp dùng, và đường hầm chỉ v4 để lưu lượng v6 ở ngoài cho tới khi chính sách theo kịp. ip -6 route show default và ip -6 addr show trả lời liệu liên kết mới có tuyến v6 nào không.
Tái tạo bước chuyển thay vì mô tả nó
Chọn một yêu cầu vô hại và chạy đúng ba lệnh đó ở hai bên thay đổi: ip -br addr, ip route show default, ip route get 203.0.113.10. Rồi xem đường hầm còn phát gói không - tcpdump -ni any udp port 51820 với WireGuard, cổng tương ứng với mọi thứ khác. Gói đi ra từ nguồn cũ nghĩa là lỗi gắn. Gói từ nguồn mới không có phản hồi nghĩa là phía xa hoặc NAT ở giữa.
Ghi lại sự kiện nào trùng với lỗi đầu tiên: liên kết xuống, đổi địa chỉ, hoặc đổi tuyến mặc định. Chúng chỉ vào những bên chịu trách nhiệm khác nhau - ứng dụng cần gắn lại, địa chỉ cần lấy lại, hoặc tuyến thuộc về một tệp cấu hình chứ không phải một quy tắc vòng tránh cố định.
Trước khi nói đã sửa, hãy xác nhận khối lưu lượng trực tiếp vẫn giữ trong suốt khoảng trống và tên được phân giải qua kết nối mới. Nếu ứng dụng vẫn giữ điểm cuối cũ sau khi chuyển, sửa thiết lập chuyển vùng hoặc float trước. Nếu nó chuyển vùng đúng mà vẫn không nhận phản hồi, xem danh tính đối tác trên máy chủ và NAT trên đường đi, và giữ cả hai bối cảnh mạng trong bản ghi để người sau so sánh được.