SSH rớt kết nối VPN mỗi phút? Không phải do keepalive

SSH kết nối, chạy được khoảng một phút rồi đóng băng ở cùng một khoảng thời gian gần như mỗi lần. Lời giải thích phổ biến là timeout nhàn rỗi, nên người ta hạ MTU và đặt keepalive phía client. Đường WireGuard tôi từng làm đã trải qua tất cả những điều đó: MTU đường hầm nhỏ hơn, cài đặt client-alive, keepalive đường hầm được cấu hình. Các lần rớt vẫn tiếp diễn không đổi. Nguyên nhân hóa ra là một tuyến LAN bất đối xứng, và mẫu này đáng để nhận ra vì nó đánh bại mọi cách sửa dựa trên bộ hẹn giờ.

Keepalive chứng minh máy chủ của bạn vẫn sẵn lòng gửi. Nó không thể khiến một thiết bị có lưu trạng thái nhìn thấy phản hồi vốn không bao giờ đi qua nó.

Huyền thoại: keepalive sửa được lần rớt âm thầm

Keepalive của SSH tồn tại cho một việc: ngăn thứ gì đó đếm sự im lặng dọn bỏ một phiên nhàn rỗi. Việc đó chúng làm tốt. Chúng không giải quyết thiết bị lưu trạng thái đã thấy gói đầu tiên theo một chiều rồi sau đó không bao giờ thấy phản hồi, vì không gì client gửi đi thay đổi giao diện mà phản hồi sử dụng.

Thay đổi MTU là cách sửa phổ biến khác, và nó có cùng kiểu thất bại. Giảm MTU giúp ích cho phân mảnh và các vấn đề MTU đường đi, và nó không làm gì cho một tuyến. Nếu bộ hẹn giờ và MTU của bạn đã hợp lý mà lần rớt vẫn xảy ra theo chu kỳ lặp lại, khoảng thời gian đó đang nói với bạn về một timeout ở đâu đó, không phải về kích thước gói. Ghi lại khoảng thời gian và so với timeout trạng thái trên mọi thiết bị trong đường đi.

Dấu hiệu là tính đều đặn cùng với một phiên vẫn dùng được trong khoảng thời gian đó. Timeout nhàn rỗi đánh khi không có gì xảy ra; cái này đánh trong lúc bạn đang gõ.

Gateway thêm thực sự làm gì

Đặt laptop và gateway VPN trên cùng một LAN, với một tường lửa LAN riêng làm gateway mặc định. Laptop gửi lưu lượng hướng tới VPN đến tường lửa, tường lửa chuyển tiếp đến gateway, và các phản hồi của gateway quay thẳng qua LAN về laptop. Chặng thứ hai đó không bao giờ đi qua tường lửa, nên bảng trạng thái của nó chỉ giữ nửa kết nối.

Các địa chỉ dưới đây phản ánh cách bố trí đó:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Chuyển hướng và xử lý trạng thái sau đó biến một handshake đang hoạt động thành kết nối chết muộn hơn thay vì ngay lập tức. Độ trễ là mục trạng thái hết hạn hoặc một kiểm tra chặt chẽ hơn thất bại, vì thế khoảng thời gian trông thật máy móc.

Không điều nào trong số này xuất hiện trong cấu hình client, vì thế việc tìm kiếm nó thường bắt đầu ở sai tệp.

Chọn một đường đi có chủ đích

Với cách bố trí trên, định tuyến subnet từ xa trực tiếp đến gateway VPN loại bỏ nửa kết nối:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Đây là các địa chỉ ví dụ. Bước nhảy tiếp theo phải tiếp cận được trên LAN của bạn, tiền tố phải là mạng từ xa dự định, và lệnh thứ hai cho bạn thấy kết quả trước khi bạn dựa vào nó. Nếu gateway không nằm trên subnet của bạn, tuyến này không phải cách sửa bạn muốn.

Nếu tường lửa nhằm giám sát lưu lượng giữa các hệ thống đó, định tuyến vòng qua nó là thiết kế sai. Thay vào đó hãy để cả hai chiều đi qua ranh giới và cấu hình tuyến mỗi bên sao cho đường về khớp. Mục tiêu là một đường đi có chủ đích duy nhất, không phải ít kiểm tra trạng thái hơn.

ghi chú về định tuyến bất đối xứng của Netgate mô tả cùng kiểu bất đối xứng ở mức giao diện và các vấn đề trạng thái mà nó tạo ra, nên hãy đọc trước khi bạn nới lỏng xử lý trạng thái trên toàn cục. Các lần ngắt kết nối theo thời gian giống trường hợp này tự chúng không phải bằng chứng. Hãy coi bài viết là mô tả một kiểu thất bại, rồi chứng minh mạng của bạn khớp với nó trước khi thay đổi chính sách trạng thái toàn cục.

Kiểm tra từ cả hai đầu

Đọc tuyến của laptop về phía đích và tuyến của đích quay về laptop; đó là hai quyết định riêng biệt và có lẽ chỉ một trong hai là sai. Một ping thành công từ chính gateway có thể che giấu hoàn toàn vấn đề, vì nó xuất phát từ máy đã có đường đi đúng. Bạn cần cả hai chiều theo cách hai đầu của phiên thực tế nhìn thấy.

Sau khi sửa, mở lại SSH và giữ phiên mở lâu hơn hẳn khoảng thời gian từng thất bại. Sau đó làm tuyến trở nên cố định trong cấu hình mạng đã được phê duyệt, vì một lệnh dùng một lần không phải kế hoạch khởi động lại và vấn đề sẽ trở lại ở lần khởi động lại tiếp theo với một bí ẩn mới.

Khi nào bất đối xứng là ổn

Định tuyến bất đối xứng là bình thường trong nhiều mạng và không hỏng theo định nghĩa. Nó trở thành vấn đề khi việc theo dõi trạng thái, dịch địa chỉ hoặc chính sách phụ thuộc vào việc nhìn thấy một đường đi mà chúng không thấy, và mỗi thứ đó có một cách khắc phục khác nhau. Hãy kiểm tra thiết bị ở giữa thực sự cần gì trước khi thiết kế lại quanh nó.

Câu trả lời bền vững nêu tên hai đường đi, thiết bị cần nhìn thấy cả hai, và tuyến giúp điều đó khả thi. Nếu bạn không thể nêu tên thiết bị, bạn chưa tìm ra nguyên nhân.