Vì sao đường hầm Azure OpenVPN rớt khoảng sáu mươi giây một lần

Đường hầm hoàn tất bắt tay, truyền lưu lượng khoảng một phút rồi kết nối lại. Trình tự đó loại trừ nghi phạm thông thường, vì tường lửa chặn cổng sẽ dừng bắt tay chứ không dừng phiên. Điều bạn gặp là bất đồng về khả năng sống: một bên kết luận bên kia đã im lặng và hạ một đường hầm đang chạy. Dòng nhật ký cho biết bên nào, và nó quyết định cách sửa.

Hãy đọc dòng đó trước khi chạm vào bất kỳ bộ hẹn giờ nào.

Lầm tưởng: có gì đó trên đường đi chặn đường hầm

Nếu một cổng bị chặn, kết nối sẽ thất bại ngay từ đầu và tiếp tục thất bại. Chu kỳ lặp lại nghĩa là thông điệp điều khiển vẫn chảy, phiên đang được thiết lập, và có gì đó về sau trong cuộc trò chuyện liên tục hết hạn. Chặn tạo ra im lặng, còn đây tạo ra nhịp.

Nhịp là manh mối hữu ích. Bộ hẹn giờ tạo ra nó; mất gói hiếm khi.

Đọc lý do ngắt kết nối trước bộ hẹn giờ

OpenVPN đặt tên cho lý do của nó, và mỗi tên chỉ một hệ thống con khác nhau. Session invalidated: KEEPALIVE_TIMEOUT là bộ hẹn giờ hết hạn, nên hãy so sánh giá trị ping và ping-restart ở cả hai đầu. AUTH_FAILED là thông tin đăng nhập hoặc trạng thái chứng chỉ, và không thay đổi bộ hẹn giờ nào giúp được. Lỗi TLS nghĩa là hai bên chưa từng tới giai đoạn keepalive.

Ghi lại thời điểm kết nối, thời điểm ngắt và liệu khoảng cách có ổn định đến từng giây hay không. Phép đo duy nhất đó tách một lịch đã cấu hình khỏi sự trùng hợp.

Khoảng ổn định là bộ hẹn giờ. Khoảng trôi dạt nhiều khả năng là vấn đề đường đi hoặc phiên bị dịch chuyển.

Hai bộ hẹn giờ keepalive chưa bao giờ thống nhất

Các hồ sơ xuất từ cổng thông tin đôi khi vẫn mang những dòng như keepalive hoặc ping-restart sao chép từ mẫu máy chủ cộng đồng. Cổng chạy cơ chế phát hiện đối tác chết của riêng nó và áp đặt kỳ vọng của riêng nó, và hai lịch không nhất thiết phải khớp. Khi chúng khác nhau, máy khách khởi động lại theo một lịch mà cổng chưa bao giờ chấp thuận.

Hai giá trị không phải cùng một điều khiển. ping là tần suất máy khách gửi tiếng dội, và ping-restart là thời gian nó chờ mà không nghe thấy gì trước khi hạ đường hầm. Một hồ sơ đặt ping-restart ngắn và một cổng phản hồi chậm sẽ khởi động lại trong mỗi giai đoạn yên tĩnh, đúng hình dạng của chu kỳ một phút.

Thay đổi nhỏ nhất ở phía máy khách là vô hiệu hóa các bộ hẹn giờ ở cấp cao nhất của hồ sơ, bên ngoài mọi khối nội tuyến:

keepalive 0 0

Lưu, tải lại hồ sơ, kết nối lại. Một phiên đã nằm trong bộ nhớ vẫn giữ giá trị cũ, đó là lý do đôi khi chỉnh sửa có vẻ như không làm gì cả.

Tên chứng chỉ có thể dịch chuyển dưới chân bạn

Xác thực bằng chứng chỉ Azure phụ thuộc vào việc máy khách có tin tên mà cổng trình bày hôm nay hay không. Một dòng verify-x509-name trong bản tải cũ có thể ghim một tên mà việc dựng lại cổng hoặc gia hạn chứng chỉ đã thay đổi từ đó, và sự không khớp hiện ra như một vòng lặp kết nối lại chứ không phải lỗi rõ ràng. Xóa dòng đó khôi phục kết nối, khiến nó thành chẩn đoán tốt và bản sửa lâu dài tồi, vì nó cũng bỏ xác minh. Khi đường hầm giữ được, hãy khôi phục dòng với tên mà cổng thực sự trình bày.

Hãy thử thế hệ máy khách thứ hai trên cùng máy trước khi sửa cổng. Nếu một máy khách lặp và máy kia giữ, hồ sơ không phải vấn đề.

Cần thay đổi gì, và theo thứ tự nào

Tiếp theo kiểm tra một phiên bị dịch chuyển. Hai thiết bị dùng chung một chứng chỉ có thể đẩy nhau ra, và kết quả có vẻ định kỳ vì cả hai bên tiếp tục kết nối lại. So sánh bản ghi phiên điểm-tới-điểm của cùng một danh tính xuất hiện hết lần này tới lần khác.

Sau đó thử đường đi không tải bằng cách chạy lưu lượng liên tục trong vài phút. Nếu các lần rớt dừng lại khi lưu lượng chảy, bộ hẹn giờ quan trọng thuộc về thiết bị NAT hoặc bộ cân bằng tải trên đường đi, không phải OpenVPN.

Chỉ nên thay đổi cài đặt cổng sau bốn bài kiểm tra này.