OpenVPN ngắt mỗi giờ: thương lượng lại hay kết nối lại thật sự?

Sáu mươi phút, hoặc ba mươi, hoặc một trăm hai mươi: một lần ngắt rơi vào khoảng tròn gần như không bao giờ là mạng. OpenVPN làm mới theo bộ đếm thời gian vật liệu khóa bảo vệ kênh dữ liệu, và một bộ đếm ngắn hơn mức bạn giả định trông đúng như một liên kết liên tục thất bại. Người dùng báo cáo kết nối bị đứt trong khi nhật ký báo cáo trao đổi khóa thành công. Hướng dẫn dưới đây tách lần làm mới đó khỏi một lần khởi động lại thật, đọc giá trị thực sự có hiệu lực và chỉ thay đổi nó sau khi chi phí đã được đặt lên bàn.

Hãy làm các bước theo thứ tự, vì bước đầu quyết định phần còn lại của trang có liên quan đến bạn hay không. Nếu nhảy cóc, bạn sẽ mất cả buổi tối tinh chỉnh bộ đếm thời gian cho một sự cố không liên quan gì đến nó.

Phân biệt đặt lại mềm với khởi động lại

Dòng nhật ký là toàn bộ chẩn đoán. Thương lượng lại ghi một lần đặt lại mềm rồi sau đó trao đổi khóa mới trong cùng đường hầm: giao diện giữ nguyên địa chỉ, các tuyến không được thêm lại, và các phiên TCP đã thiết lập thường sống sót với một khoảng dừng. Khởi động lại thật xé phiên, dựng lại giao diện, có thể cấp địa chỉ máy khách khác và giết mọi kết nối dài hạn. Cả hai sự kiện đều bình thường; chỉ một trong hai giải thích một cuộc gọi bị ngắt.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

Dòng phiên bản quan trọng vì cách diễn đạt trong nhật ký thay đổi giữa các bản phát hành, và một thông điệp bạn nhớ từ 2.3 có thể được viết khác trong 2.6. Hãy đọc nhật ký của chính bạn thay vì trích đoạn diễn đàn của người khác. Trích dẫn đúng dòng khi bạn nhờ trợ giúp, vì diễn giải lại làm mất chi tiết nhận diện sự kiện. Nếu địa chỉ giao diện không đổi trong suốt sự kiện và danh sách phiên vẫn sống, bạn đang thấy một lần làm mới và các phần còn lại vẫn áp dụng.

Đọc bộ đếm thời gian hiệu lực, không phải tệp của bạn

reneg-sec là số giây giữa các lần thương lượng lại của kênh dữ liệu và giá trị mặc định là 3600. Mỗi bên mang giá trị riêng, và giá trị nhỏ hơn trong hai là thứ thực sự kích hoạt việc làm mới. Một quy tắc đó giải thích phần lớn các báo cáo: một hồ sơ máy khách đặt số lớn vẫn bị đặt lại mỗi giờ chừng nào máy chủ giữ giá trị mặc định.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Cũng hãy đọc cấu hình hiệu lực của máy chủ, gồm mọi thứ nó đẩy xuống, trước khi kết luận từ tệp máy khách. Sau đó nâng mức chi tiết và quan sát một khoảng từ đầu đến cuối: mức 3 đã hiển thị các dòng thương lượng lại, và dấu thời gian cho biết sự kiện lặp lại mỗi 3600 giây hay thay vào đó đi theo hoạt động.

Thay đổi ở nơi nó thực sự được đẩy xuống

Phương thuốc lưu truyền là một dòng trong hồ sơ máy khách, và khoảng một nửa thời gian đó là sai chỗ. Vì giá trị thấp hơn của bên thắng, một máy khách đặt bộ đếm về không vẫn có thể bị máy chủ không thay đổi thương lượng lại.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Khi hồ sơ được tạo tập trung, hãy sửa mẫu chứ không phải bản sao đã triển khai, nếu không lần chạy cung cấp tiếp theo sẽ khôi phục giá trị bạn vừa gỡ. Kiểm chứng bằng cách quan sát hai khoảng, không phải một: một giờ yên tĩnh cũng khớp với bộ đếm được đặt thành 7200.

Cũng hãy quyết định điều gì xảy ra khi triển khai hỗn hợp. Nếu đẩy thay đổi tới máy khách trước, sẽ còn một cửa sổ mà máy chủ vẫn kích hoạt việc làm mới; điều đó vô hại nhưng gây bối rối nếu bạn theo dõi nhật ký để xác nhận. Hãy đổi bên giữ giá trị nhỏ hơn trước và triệu chứng sẽ biến mất đúng điểm bạn chờ đợi.

Bạn từ bỏ điều gì khi tắt thương lượng lại

Thương lượng lại định kỳ giới hạn thời gian một bộ khóa kênh dữ liệu bảo vệ lưu lượng. Tắt bộ đếm không làm gãy đường hầm, và trên router gia đình hay cổng văn phòng nhỏ, mức phơi nhiễm thực tế là khiêm tốn. Đó vẫn là một trao đổi, và trao đổi đó đáng được nêu ra trước khi bạn thực hiện. Điều thay đổi là một bộ khóa bảo vệ một phiên trong bao lâu, không phải đường hầm có hoạt động hay không.

Trường hợp hợp lý để tắt là một lần đặt lại làm hỏng thứ không thể tiếp tục: một cuộc gọi bị rớt, một phiên máy tính để bàn từ xa phải thiết lập lại, một bản sao lưu khởi động lại từ đầu. Nếu khoảng dừng không thấy được với người dùng, giữ giá trị mặc định không tốn gì và bảo toàn vòng xoay khóa bạn được cấp.

Nên ưu tiên sửa nguyên nhân khi kiểu mẫu cho phép. Một lần làm mới thất bại giữa chừng trong khi cái bắt tay đầu tiên thành công chỉ vào đường đi chứ không phải bộ đếm: hãy tìm vấn đề kích thước gói trong trao đổi kênh điều khiển lớn hơn, một tường lửa có trạng thái làm rớt luồng, hoặc một đề xuất chỉ thành công ở lần thử đầu. Mỗi thứ đều để lại dấu vết trong cùng nhật ký bạn vừa đọc. Tắt bộ đếm sẽ che giấu bằng chứng đó.

Khi khoảng thời gian chỉ vào nơi khác

Hai người hàng xóm trong cấu hình tạo ra triệu chứng giống nhau và cách sửa khác nhau. ping-restart khởi động lại đường hầm khi không có gì đến trong một khoảng đã đặt, trong khi ping-exit hạ máy khách xuống hoàn toàn. Một lần ngắt khi nhàn rỗi mà không có thương lượng lại ở bất kỳ đâu trong nhật ký thuộc về những thứ này, hoặc về một thiết bị NAT đã để ánh xạ UDP hết hạn theo lịch riêng của nó.

Router tiêu dùng, điểm phát sóng di động và NAT cấp nhà mạng đều để các phiên UDP nhàn rỗi hết hạn mà không báo cho ai. Lỗi đó đi theo sự nhàn rỗi chứ không theo đồng hồ, và đó là dấu hiệu: một phiên rớt sau mười phút yên tĩnh và sống qua một giờ lưu lượng đều đặn không phải đang thương lượng lại.

Ghi lại ba điều trước khi đổi điều thứ tư: khoảng bạn đã đo, giá trị hiệu lực bạn tìm thấy và lệnh đã hiển thị nó. Nếu khoảng dịch chuyển khi bộ đếm dịch chuyển, cơ chế đã được nhận diện và cách sửa là một quyết định về trao đổi ở trên. Nếu nó không dịch chuyển, hãy trả cài đặt lại và tiếp tục xem keepalive, trạng thái NAT và mất gói.