VPN liên tục ngắt kết nối? Hãy xử lý theo thứ tự này

Trước khi cài lại ứng dụng khách, hãy ghi ba điều: đường hầm duy trì được bao lâu, ứng dụng khách nói gì khi ngắt và máy có ngủ hoặc đổi mạng trong khoảng đó không. Ghi chú ấy là bằng chứng duy nhất bạn sẽ có về sau, và việc cài lại thường xóa nó đi. Ngắt theo khoảng lặp lại là bộ hẹn giờ hoặc trạng thái hết hạn; ngắt vào thời điểm ngẫu nhiên là vấn đề đường truyền. Thứ tự dưới đây giúp bạn không thay đổi ba thứ cùng lúc mà không học được gì.

Bước một: ghi lại khoảng thời gian và nội dung lỗi

Hãy bắt đầu từ nhật ký của chính ứng dụng khách chứ không phải trang quản trị của nhà cung cấp. Trên ứng dụng khách Linux, nhật ký dịch vụ cùng trạng thái trực tiếp của đường hầm bao quát phần lớn:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Ghi lại dấu thời gian của lần bắt tay thành công cuối cùng và thời điểm lưu lượng dừng lại, không chỉ thời điểm biểu tượng đổi màu. Một ứng dụng khách GUI báo ngắt sau khi sự việc xảy ra có thể đang báo trạng thái mà nhân hệ điều hành đã đạt vài giây trước đó.

Giữ nguyên cách diễn đạt của lỗi. Hết thời gian, bị từ chối xác thực và lỗi bộ điều hợp hoặc trình điều khiển chỉ vào ba lớp khác nhau, và phần lớn công sức lãng phí trong vấn đề này đến từ việc coi chúng là một. Sao chép nguyên dòng vào ghi chú của bạn.

Bước hai: thay đổi một biến, không phải hồ sơ

Giữ cố định thiết bị và hồ sơ rồi chuyển máy sang mạng truy cập khác, chẳng hạn điểm phát sóng từ điện thoại. Đây là phép thử rẻ nhất để tách ứng dụng khách khỏi đường truyền. Chạy đủ lâu để bao trùm khoảng lỗi ban đầu; hai phút ổn định không chứng minh gì về lần ngắt xảy ra ở phút thứ ba mươi.

Một laptop có cổng Ethernet cho phép so sánh thứ hai loại bỏ hoàn toàn Wi-Fi khỏi bức tranh. Nếu đường hầm giữ được trên cả hai phương án, mạng truy cập ban đầu đáng được chú ý: chuyển vùng giữa các điểm truy cập, bộ định tuyến gia đình có bảng dịch địa chỉ hết hạn, hoặc liên kết thượng nguồn đặt lại các luồng dài.

Ghi lại biến nào bạn đã thay đổi. Một so sánh chỉ có giá trị khi mọi thứ khác giữ nguyên, và điều đó bao gồm điểm cuối của máy chủ cùng thời điểm trong ngày.

Bước ba: gắn khoảng thời gian với một lớp

Độ dài của một phiên tốt là con số đơn lẻ giàu thông tin nhất bạn có. Hãy đọc nó đối chiếu với danh sách này trước khi chạm vào bộ hẹn giờ:

• Ngắt sau khi ngủ hoặc khôi phục: trạng thái đường hầm sống sót qua lần tạm dừng nhưng giao diện thì không. Kiểm tra hành vi kết nối lại của ứng dụng khách khi khôi phục và việc dịch vụ khởi động lại đường hầm hay chờ lưu lượng.
• Chỉ ngắt khi không hoạt động: có gì đó ở giữa đã để luồng hết hạn. keepalive tồn tại chính cho trường hợp này.
• Ngắt ở độ tuổi phiên cố định: sự kiện xác thực lại hoặc gia hạn khóa, không phải lỗi đường truyền. Một lời từ chối rõ ràng trong nhật ký đúng khoảng đó là dấu hiệu.
• Ngắt trong lúc truyền lớn hoặc trang lớn: hãy nghi MTU và phân mảnh, không phải bộ hẹn giờ nhàn rỗi.

Với trường hợp nhàn rỗi, cài đặt phụ thuộc giao thức và cả hai đầu đều quan trọng. keepalive 10 60 của OpenVPN trên máy chủ gửi ping mỗi 10 giây và khởi động lại liên kết sau 60 giây không có ping; ứng dụng khách WireGuard sau NAT dùng PersistentKeepalive = 25 trong khối đồng cấp. OpenVPN cũng thương lượng lại kênh dữ liệu theo bộ hẹn giờ, reneg-sec, mặc định là 3600 giây ở phiên bản 2.x.

Đừng sao chép các giá trị hung hăng từ hướng dẫn của nhà cung cấp khác. Thời gian chờ ngắn trên liên kết di động có mất gói tạo ra đúng những lần ngắt mà nó lẽ ra phải ngăn, và giá trị do máy chủ đẩy xuống sẽ ghi đè những gì bạn đặt trong hồ sơ ứng dụng khách.

Bước bốn: so sánh một phương án được hỗ trợ

Nếu nhà điều hành công bố cả hồ sơ UDP và TCP, hãy chạy cùng thiết bị và mạng với phương án kia. Dùng đúng tệp tương ứng thay vì sửa giao vận trong một hồ sơ đã sao chép. Một hồ sơ TCP ổn định trên đường truyền nơi UDP bị đặt lại sẽ thu hẹp vấn đề vào đường đó; nó không chứng minh TCP là giao vận tốt hơn ở mọi nơi.

Logic tương tự áp dụng cho các điểm cuối. Hãy thử một máy chủ khác và giữ kết quả ban đầu bên cạnh. Nếu chỉ một lối ra đặt lại phiên, đó là bằng chứng về điểm cuối ấy, không phải lý do dựng lại mọi bộ điều hợp trên laptop.

Sau mọi thay đổi, hãy lặp lại tác nhân kích hoạt ban đầu và xác nhận lưu lượng thực sự đi đâu. Truy cập internet được khôi phục không phải cùng kết quả với lưu lượng bên trong đường hầm, và một ứng dụng khách âm thầm rơi về tuyến trực tiếp trông vẫn khỏe từ trình duyệt.

Xác minh bản sửa và giữ khả năng quay lui

Một bản sửa được xác minh bằng cách tái tạo tác nhân kích hoạt ban đầu, không phải bằng một kết nối thành công. Hãy để đường hầm nhàn rỗi vượt khoảng lỗi cũ, tạm dừng và khôi phục một lần, rồi kiểm tra tuổi của bắt tay và địa chỉ ra:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Giữ hồ sơ trước đó và các giá trị hẹn giờ trước đó cho đến khi hành vi mới sống sót qua một ngày làm việc trọn vẹn. Nếu các lần ngắt quay lại, hãy khôi phục bản sao lưu, rồi áp dụng lại từng thay đổi một để lần thử thứ hai bắt đầu từ trạng thái đã biết.

Nếu nhật ký vẫn sạch mà đường hầm vẫn ngắt theo khoảng lặp lại, điểm dừng tiếp theo là phía máy chủ cho phiên đó. Mang theo mã định danh phiên của ứng dụng khách và thời điểm ngắt chính xác, vì chính cặp đó làm cho nhật ký máy chủ có thể tìm kiếm được. Các tùy chọn liên kết của giao thức được ghi trong hướng dẫn OpenVPN 2.6 khi bạn cần ý nghĩa chính xác của một giá trị.