it-swarm-vi.com

Kết nối mồ côi ở trạng thái CLOSE_WAIT

Tôi đã có một máy SLES tích lũy TCP kết nối ở trạng thái CLOSE_WAIT cho những gì dường như là mãi mãi. Những mô tả này cuối cùng đã hút hết bộ nhớ khả dụng. Hiện tại, tôi có 3037 chúng, nhưng nó đã cao hơn nhiều trước khi khởi động lại nhanh chóng gần đây.

Điều thú vị là chúng không phải từ các kết nối đến các cổng cục bộ mà tôi mong đợi có quá trình lắng nghe. Chúng không có PID liên quan và bộ định thời của chúng dường như đã hết hạn.

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -     

Tôi không phải là đai đen khi nói đến ngăn xếp TCP hoặc mạng kernel, nhưng cấu hình TCP có vẻ lành mạnh, vì các giá trị này là mặc định , trên mỗi trang nam:

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

Vì vậy, những gì cho? Nếu bộ định thời đã hết hạn, không nên ngăn xếp tự động xóa công cụ này? Tôi thực sự mang lại cho mình một DoS dài hạn khi những thứ này tích tụ.

30
pboin

Không, không có thời gian chờ cho CLOSE_WAIT. Tôi nghĩ đó là ý nghĩa của off trong đầu ra của bạn.

Để thoát khỏi CLOSE_WAIT, ứng dụng phải đóng ổ cắm một cách rõ ràng (hoặc thoát).

Xem Cách ngắt CLOSE_WAIT .

Nếu netstat đang hiển thị - trong cột quy trình:

  • bạn có đang chạy với các đặc quyền và khả năng phù hợp (ví dụ như là root) không?
  • chúng có thể là các tiến trình kernel (ví dụ: nfsd)
16
Mikel

CLOSE_WAIT chỉ ra rằng máy khách đang đóng kết nối nhưng ứng dụng chưa đóng hoặc máy khách thì không. Bạn nên xác định chương trình hoặc chương trình nào đang gặp vấn đề này. Hãy thử sử dụng

netstat -tonp 2>&1 | grep CLOSE

để xác định chương trình nào đang giữ các kết nối.

Nếu không có chương trình nào được liệt kê, thì dịch vụ đang được cung cấp bởi kernel. Đây có thể là các dịch vụ RPC như nfs hoặc rpc.lockd. Nghe các dịch vụ kernel có thể được liệt kê với

netstat -lntp 2>&1 | grep -- -  

Trừ khi các dịch vụ RPC bị ràng buộc với các cổng cố định, chúng sẽ liên kết với các cổng phù du khi các kết nối của bạn xuất hiện. Bạn cũng có thể muốn kiểm tra các quy trình và gắn kết trên máy chủ khác.

Bạn có thể liên kết các dịch vụ NFS của mình với các cổng cố định bằng cách thực hiện như sau:

  1. Chọn bốn cổng không sử dụng cho NFS (32763-32766 được sử dụng tại đây)
  2. Thêm các cổng cố định cho NFS vào /etc/services [.__.]
    rpc.statd-bc 32763/udp # RCP statd phát [.__.] rpc.statd-bc 32763/tcp [.__.] rpc.statd 32764/udp # RCP statd lắng nghe [.__.] tcp [.__.] rpc.mountd 32765/udp # RPC mountd [.__.] rpc.mountd 32765/tcp [.__.] rpc.lockd 32766/udp # RPC lockd/nlockmgr [.__. 32766/tcp
  3. Định cấu hình statd để sử dụng các tùy chọn --port 32763 --outgoing-port 32764
  4. Định cấu hình rpcmountd để sử dụng tùy chọn --port 32765
  5. Tắt máy và khởi động lại dịch vụ NFS và RPC.
10
BillThor