VPN liên tục mất kết nối: kiểm tra sóng trước khi đổ lỗi máy chủ

Mất kết nối VPN có thể bắt đầu rất lâu trước khi bất kỳ lưu lượng nào đến máy chủ. Mất Wi-Fi, chuyển từ Wi-Fi sang mạng di động, tắc nghẽn tại điểm truy cập cục bộ và điện thoại ngủ có thể làm gián đoạn đường đi bên ngoài trong khi phần mềm đường hầm báo một lỗi sạch. Hãy đi từ thiết bị ra ngoài: trước tiên là liên kết, sau đó là sự kiện của chính ứng dụng khách, sau đó là so sánh có kiểm soát và cuối cùng mới là máy chủ. Thứ tự đó giữ bạn khỏi việc đổi nút lối ra cho một vấn đề nằm ngay trong phòng.

Nhìn vào liên kết, không phải biểu tượng sóng

Hãy tìm các chuyển tiếp liên kết thay vì các vạch sóng. Thiết bị có thể hiển thị sóng mạnh trong khi điểm truy cập đã bão hòa, trong khi đang chuyển vùng hoặc trong khi chính sách tiết kiệm điện tắt sóng khi màn hình tắt.

Ghi lại trạng thái giao diện, cổng hiện tại và thời điểm của mỗi thay đổi. Sau đó kiểm tra xem mất kết nối có trùng với chuyển tiếp đó không. Một lần rớt xảy ra mỗi khi điện thoại di chuyển giữa các phòng là vấn đề liên kết cho đến khi chứng minh ngược lại, bất kể ứng dụng hiển thị máy chủ nào.

Đọc các sự kiện kết nối lại của ứng dụng khách

Hầu hết ứng dụng khách ghi lại lý do mất kết nối và dấu thời gian cho lần thử tiếp theo. Một đường hầm thương lượng lại trong vài giây rồi hoạt động là sự kiện khác với một đường hầm nằm im cho đến khi bạn bật lại bằng tay.

Các lần kết nối lại ngắn lặp đi lặp lại chỉ vào đường đi bên ngoài, vì ứng dụng khách vẫn đến được máy chủ và mất phiên. Một đường hầm nằm im chỉ vào xác thực, thay đổi điểm cuối hoặc chính sách, vì ứng dụng khách không đi đủ xa để mất gì. Hãy đọc hai mẫu riêng rẽ trước khi chạm vào cấu hình.

So sánh điểm cuối thứ hai cẩn thận

Điểm cuối thứ hai là một so sánh hữu ích và tự nó không phải là thí nghiệm có kiểm soát. Nó thay đổi tuyến đường, hạ tầng và thường cả quốc gia, nên một khác biệt giữa hai điểm cuối không chứng minh máy chủ đầu tiên bị lỗi.

Giữ thiết bị, mạng truy cập và khối lượng công việc cố định và ghi lại những gì khác đã thay đổi khi bạn chuyển. Nếu cả hai điểm cuối cùng hỏng ở cùng một thời điểm và cùng một nơi, đường đi cục bộ là nhân tố chung. Nếu chỉ một điểm hỏng, máy chủ hoặc tuyến đường đến đó trở thành manh mối chính. Hãy ghi lại các yếu tố gây nhiễu để kết luận không vượt trước bằng chứng.

Tương quan với máy chủ bạn chạy

Nếu bạn quản trị điểm cuối, hãy khớp thời điểm thử với nhật ký của trình lắng nghe và liên kết. Nhiều ứng dụng khách không liên quan cùng hỏng trên một cổng là bằng chứng khác với một điện thoại rớt mỗi khi di chuyển.

Một phản hồi từ đối tác không xác lập sức khỏe ứng dụng liên tục. Sau khi phục hồi, hãy kiểm tra tài nguyên bạn thực sự cần, vì một cái bắt tay thành công và máy chủ tiếp cận được có thể cùng tồn tại với đường đi ứng dụng bị hỏng.

Viết báo cáo thu hẹp phạm vi

Hãy tách bốn phát biểu: mất liên kết cục bộ, khả năng tiếp cận bên ngoài, thương lượng đường hầm và trạng thái của chính ứng dụng. Mỗi cái có bằng chứng riêng, và một báo cáo giữ chúng tách biệt sẽ cho người tiếp theo biết nên nhìn ở đâu.

Cũng ghi lại các giới hạn của so sánh. Nếu chính sách ngăn một thử nghiệm đường đi trực tiếp, hãy nói ra thay vì trình bày so sánh điểm cuối như bằng chứng. Nhãn quốc gia trong ứng dụng không xác định toàn bộ tuyến đường, và một máy chủ gần về địa lý vẫn có thể được tiếp cận qua một đường đi tắc nghẽn.

Trang giới hạn đã biết của dự án WireGuard là lời nhắc hữu ích rằng một giao thức có thể đúng mà vẫn để hành vi liên kết cho hệ điều hành. Kết thúc bằng việc lặp lại cùng thử nghiệm sau lần mất kết nối tiếp theo, vì một sự kiện là một điểm dữ liệu và một mẫu là một chẩn đoán.