Nếu cổng phía trước vẫn chấp nhận kết nối sau khi SSH thoát, hãy kiểm tra cả ba unit. Socket kích hoạt, trình trợ giúp systemd-socket-proxyd và trình lắng nghe SOCKS do SSH tạo có vòng đời khác nhau:

SocketTrình trợ giúpSSHDiễn giải
Đang lắng ngheKhông hoạt độngKhông hoạt độngCó thể đang chờ nhu cầu một cách bình thường
Đang lắng ngheĐang hoạt độngĐang hoạt độngCác tiến trình tồn tại; tình trạng của đích tiếp theo vẫn chưa được chứng minh
Đang lắng ngheĐang hoạt độngKhông hoạt độngPhía trước có thể nhận việc mà không có phần phía sau

Khởi động trình trợ giúp và SSH cùng nhau không xác định bước chuyển dừng về sau. Với trình trợ giúp không được phép tiếp tục hoạt động khi thiếu đường hầm, systemd ghi nhận một quan hệ mạnh hơn:

[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.service

Áp dụng nó cho unit thích hợp trong thiết kế thực tế. Requires= và thứ tự chỉ giải quyết một phần của quan hệ. Phía trước vốn đã hoạt động có thể sẽ không bao giờ kích hoạt lại sau khi phần phía sau biến mất. Cũng hãy kiểm tra trạng thái unit lỗi và giới hạn tốc độ khởi động; các phụ thuộc không vô hiệu hóa những giới hạn đó.

Tiếp theo, thiết lập mức sẵn sàng khởi động. After= sắp xếp các công việc, không phải mức sẵn sàng của một trình lắng nghe SSH Type=simple. Một khoảng chờ cố định có thể thất bại khi xác thực chậm. Hãy dùng một giao ước khởi động thiết lập trình lắng nghe cần thiết; ExitOnForwardFailure=yes bắt được lỗi thiết lập chuyển tiếp, không phải khả năng tiếp cận đích về sau.

Cuối cùng, xác định việc thoát khi nhàn rỗi và kích hoạt lại. Tùy chọn thoát khi nhàn rỗi của daemon chuyển tiếp liên quan đến việc không có kết nối hoạt động, không phải thiếu byte trên một kết nối đang mở. Một phiên im lặng có thể giữ nó hoạt động. Nhu cầu tiếp theo nên kích hoạt các dịch vụ cần thiết, và các vòng khởi động lại nên được giới hạn và hiển thị. Tạo lại trình lắng nghe chấp nhận kết nối mới; nó không khôi phục các phiên TCP đã được proxy trước đó.

Bài viết liên quan