Vì sao VPN của bạn mất nhiều thời gian phục hồi hơn cả sự cố

Wi-Fi đã trở lại ba mươi giây trước mà VPN vẫn tắt, nên máy khách trông như hỏng. Thường thì nó chỉ đang tuân theo lịch thử lại của chính mình, và lịch đó không biết mạng vừa trở lại. Khoảng trống ấy chính là toàn bộ câu chuyện: thời gian phục hồi là sự cố cộng với bất kỳ khoảng chờ nào mà máy khách đã cam kết. Hạ mọi bộ đếm thời gian là một câu trả lời, và hiểu bộ đếm nào quan trọng là câu trả lời kia.

Ba điều kiện quyết định việc tinh chỉnh có giúp ích hay không: giai đoạn nào chậm, lỗi có thể thử lại được hay không, và máy khách biết mạng đã trở lại bằng cách nào.

Ba khoảng chờ trông như một

Việc phân giải điểm cuối, đàm phán IKE hoặc TLS, truyền lại gói tin và bắt đầu một lần thử mới là những sự kiện riêng biệt với bộ đếm thời gian riêng. strongSwan ghi lại cơ chế lùi dần khi truyền lại cho IKE, còn OpenVPN có các điều khiển thử lại riêng với ngữ nghĩa khác. Sao chép một con số từ cái này sang cái kia giả định rằng các cơ chế giống nhau, nhưng chúng không giống. Hãy đọc trình tự trong nhật ký trước khi quyết định bạn đang xem khoảng nào.

Một phút im lặng trong nhật ký không hẳn là tiến trình bị treo. Đó có thể là cơ chế lùi dần theo cấp số nhân đang làm đúng điều nó được cấu hình để làm.

Giai đoạn nào thực sự chậm?

Nếu nhật ký cho thấy các lần thử thất bại với lỗi xác thực, mọi thay đổi bộ đếm đều không giúp được, vì thông tin đăng nhập sai. Nếu hoàn toàn không có lần thử nào, máy khách đang trong cửa sổ chờ và lịch chính là giải pháp. Nếu có lần thử và chúng hết thời gian, vấn đề là khả năng tiếp cận hoặc thiếu bộ lắng nghe, và thử lại nhanh hơn chỉ làm đầy nhật ký. Mỗi trạng thái trong ba trạng thái đó có một người chịu trách nhiệm khác nhau, và chỉ một trong số đó là vấn đề thời gian.

Hãy phân loại lỗi trước khi chạm vào một con số.

Khi nào hạ bộ đếm thời gian giúp ích và khi nào không

Hãy hạ trần thử lại khi chi phí chủ yếu là chờ đợi sau một sự cố ngắn, thường xuyên, như một máy tính xách tay di chuyển giữa các điểm truy cập. Hãy để yên khi lỗi kéo dài hoặc hiếm gặp, vì thử lại hung hăng sẽ thêm tải đúng vào lúc bộ tập trung ít có khả năng trả lời nhất. Trong cả hai trường hợp, hãy thay đổi một tham số, ghi lại nó và đo lần phục hồi tiếp theo thay vì cho rằng nó đã tốt hơn.

Thời gian chờ rất thấp bị sao chép vào mọi hồ sơ là trạng thái cuối thường thấy của việc tinh chỉnh mà không đo lường.

Hãy kiểm tra mức sẵn sàng trước khi đổ lỗi cho máy khách

Máy khách thường không thể thấy mạng dùng được cho đến khi có thứ gì đó thử. Một cổng bắt giữ, việc gia hạn DHCP hoặc thay đổi tuyến có thể khiến nó chờ theo một lịch được đặt trước khi bất kỳ điều gì trong số đó xảy ra. Hãy quan sát thay đổi trạng thái mạng của hệ điều hành và lần thử tiếp theo của máy khách trên cùng một đồng hồ, bạn sẽ thấy đó là sự chờ của ai. Cách nhanh là ghi lại mốc thời gian của sự kiện mạng sẵn sàng và mốc thời gian của lần thử đầu tiên sau đó.

Cũng hãy xác nhận rằng lưu lượng trực tiếp vẫn bị chặn trong lúc chờ, vì kết nối lại nhanh hơn mà rò rỉ lưu lượng không phải là cải thiện.

Cần ghi lại những gì

Hãy ghi lại bộ đếm nào đã thay đổi, từ giá trị nào sang giá trị nào, và lần phục hồi sau đó trông thế nào. Cũng ghi lại phiên bản máy khách, vì giá trị mặc định thay đổi giữa các bản phát hành và một thời gian chờ rất thấp không được ghi chú sẽ khiến người tiếp theo đọc hồ sơ bối rối.

Bản ghi đó biến lần nâng cấp phần mềm tiếp theo thành một so sánh chứ không phải một thử nghiệm.