VPN ngắt kết nối đúng cùng một khoảng? Khớp bộ đếm thời gian

Một đường hầm chết mỗi mười lăm phút, hoặc mỗi giờ vào cùng một phút, cho bạn biết một bộ đếm thời gian nào đó đã hết hạn, chứ không phải mạng không ổn định. Động thái hữu ích là ghi lại khoảng thời gian và so sánh nó với bốn bộ đếm tạo ra kiểu này. Thay đổi thời gian chờ trước phép so sánh đó thường chỉ di chuyển lỗi mà không giải thích nó, khiến lần tiếp theo khó đọc hơn lần đầu. Việc đo mất mười phút và thay thế một tuần phỏng đoán.

Biến khoảng thời gian thành con số

Thu thập năm hoặc sáu lần xuất hiện và tính khoảng cách giữa chúng, không phải khoảng cách từ đầu ngày. Rớt lúc 09:12, 10:12 và 11:12 là ranh giới theo giờ; rớt lúc 09:12, 09:27 và 09:42 là mười lăm phút kể từ kết nối thành công cuối cùng. Làm tròn kết quả đến bộ đếm khả dĩ nhất, không phải đến phút gần nhất.

Ghi lại hai thời điểm cho mỗi sự kiện: khi lưu lượng di chuyển lần cuối và khi máy khách báo mất kết nối. Chúng khác nhau khi đường hầm chết lặng lẽ và máy khách chỉ nhận ra ở lần gửi tiếp theo, và chính sự khác biệt đó tách thời gian chờ nhàn rỗi khỏi lỗi cứng. Máy khách nhận ra muộn sẽ thổi phồng cửa sổ nhàn rỗi mà bạn đo.

Để ý xem việc kết nối lại có tự động không. Máy khách kết nối lại trong vài giây giữ khoảng thời gian hiển thị trong nhật ký và nằm ngoài báo cáo người dùng, vì thế những lỗi này thường được mô tả là thỉnh thoảng chứ không phải định kỳ. Nó cũng giấu sự kiện khỏi người đang dùng máy tính xách tay.

Bốn bộ đếm trông giống nhau

Gần như mọi cú rớt đường hầm lặp lại đều đến từ một trong những thứ này: làm mới khóa giao thức, hết hạn ánh xạ nhàn rỗi, sự kiện DHCP hoặc giao diện, hoặc chính sách tài khoản. Chúng khác nhau ở chỗ có lưu lượng hay không và ở điều nhật ký nói tại ranh giới.

Các dấu hiệu dưới đây đáng học, vì chúng cho phép bạn loại bỏ ba cách giải thích chỉ từ một dòng nhật ký:

Dòng đầu là một cơ chế bảo mật đang làm việc của nó, còn dòng thứ hai là thiết bị trung gian quên trạng thái. Nhầm lẫn hai thứ này dẫn đến việc làm yếu quá trình làm mới khóa hoặc đuổi theo một quy tắc tường lửa chưa từng liên quan.

Bận so với nhàn rỗi cho bạn biết nửa nào

Thực hiện so sánh có kiểm soát với lưu lượng liên tục, ví dụ một luồng dài tới máy chủ bên trong đường hầm, và xem khoảng thời gian có thay đổi không. Nếu cú rớt biến mất khi dữ liệu đang chảy, bộ đếm dựa trên nhàn rỗi.

Nếu nó sống sót qua lưu lượng liên tục, nguyên nhân thuộc về làm mới khóa, thuê hoặc chính sách. Phép thử duy nhất đó loại bỏ một nửa ứng viên trong khoảng một giờ quan sát, và nó không tốn gì ngoài sự chú ý.

Giữ nguyên mạng truy cập trong suốt phép thử. Chuyển giữa Wi-Fi và Ethernet ở giữa phép so sánh đưa vào đúng sự kiện giao diện mà bạn đang cố phân biệt với bộ đếm.

Khớp dòng nhật ký với ranh giới

Đọc nhật ký máy khách và máy chủ quanh thời điểm đã ghi, không phải toàn bộ tệp. Làm mới khóa cho thấy đàm phán; hết hạn nhàn rỗi không cho thấy gì cho đến gói tiếp theo; thay đổi thuê cho thấy công việc địa chỉ; giới hạn chính sách thường cho thấy ngắt kết nối quản trị sạch sẽ.

Các lệnh này lấy cửa sổ liên quan từ mỗi nguồn:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

Nếu ba nguồn khớp nhau về dấu thời gian, bạn biết chủ của bộ đếm. Nếu chỉ nhật ký máy khách có gì đó, máy chủ có lẽ không phải bên kết thúc phiên.

Sửa giai đoạn, không phải biểu tượng

Mỗi chủ có một cách sửa được hỗ trợ. Lỗi làm mới khóa cần đề xuất tương thích ở cả hai đầu. Hết hạn nhàn rỗi cần tín hiệu duy trì hoặc kỳ vọng nhàn rỗi ngắn hơn, trong giới hạn mà đường đi cho phép. Sự kiện thuê cần chỉnh cài đặt giao diện hoặc nguồn. Giới hạn tài khoản là quyết định chính sách, không phải lỗi.

Tắt làm mới khóa hoặc xác thực để giữ biểu tượng xanh là đánh đổi một cú rớt thấy được lấy một điểm yếu không thấy được, và khiến bạn không thể nói đường hầm đàm phán khóa mới lần cuối khi nào. Hãy thử lại thời lượng ban đầu sau đó và giữ các dấu thời gian, để sự kiện tiếp theo có thể so với lần này thay vì bắt đầu lại.