У нас есть клиент-серверная установка, где клиент настраивает SSH-туннель и использует переадресацию портов для отправки данных на сервер:
ssh -N -L 5000:localhost:5500 user@serveraddress
Нормальное количество SSH-соединений на сервере составляет ~ 150, и, хотя все в порядке, серверное программное обеспечение обрабатывает входящие соединения довольно быстро (максимум несколько секунд).
Однако недавно мы заметили, что количество SSH-соединений увеличивается до 900+. На этом этапе серверное программное обеспечение видит, подключается к нему и принимает эти подключения, но данные не поступают.
Кто-нибудь видел раньше такие симптомы с SSH? Есть идеи, в чем может быть проблема?
Server OS: Red Hat Linux 5.5
Firewall: Disabled
Key Exchange: Tested
РЕДАКТИРОВАТЬ: Добавление частей данных журнала из / var / log / secure на стороне сервера
Похоже, что в файле журнала много следующего.
Apr 10 00:07:33 myserver sshd[15038]: fatal: Write failed: Connection timed out
Apr 10 00:12:01 myserver sshd[5259]: fatal: Read from socket failed: Connection reset by peer
Apr 10 00:44:48 myserver sshd[17026]: fatal: Write failed: No route to host
Apr 10 02:09:16 myserver sshd[10398]: fatal: Read from socket failed: Connection reset by peer
Apr 10 02:22:47 myserver sshd[24581]: fatal: Read from socket failed: Connection reset by peer
Apr 10 03:05:57 myserver sshd[12003]: fatal: Read from socket failed: Connection reset by peer
Apr 10 03:23:19 myserver sshd[22421]: fatal: Write failed: Connection timed out
Apr 10 08:13:43 myserver sshd[31993]: fatal: Read from socket failed: Connection reset by peer
Apr 10 08:36:39 myserver sshd[7759]: fatal: Read from socket failed: Connection reset by peer
Apr 10 09:02:32 myserver sshd[12470]: fatal: Write failed: Broken pipe
Apr 10 12:08:05 myserver sshd[728]: fatal: Write failed: Connection reset by peer
Apr 10 12:35:53 myserver sshd[6184]: fatal: Read from socket failed: Connection reset by peer
Apr 10 12:43:14 myserver sshd[2663]: fatal: Write failed: Connection timed out
НОТА: Примерно через 10-15 минут после 900+ подключений система восстановится сама - количество подключений упадет до нормального диапазона, и сервер снова начнет получать данные. Похоже на DOS / DDOS, но это во внутренней сети.
ДОБАВЛЕНИЕ: Проверял статус подключений на основании вопроса @kranteg. У нас только что произошел очередной сбой, и это результаты на основе сценария, который я написал для всех входящих SSH-соединений:
===
Tue Apr 15 12:22:07 EDT 2014 -> Total SSH connections: 996
===
0 SYN_SENT
1 SYN_RECV
0 FIN_WAIT1
0 FIN_WAIT2
15 TIME_WAIT
0 CLOSED
760 CLOSE_WAIT
143 ESTABLISHED
77 LAST_ACK
0 LISTEN
0 CLOSING
0 UNKNOWN
===
===
Tue Apr 15 12:22:17 EDT 2014 -> Total SSH connections: 977
===
0 SYN_SENT
2 SYN_RECV
1 FIN_WAIT1
0 FIN_WAIT2
15 TIME_WAIT
0 CLOSED
756 CLOSE_WAIT
127 ESTABLISHED
76 LAST_ACK
0 LISTEN
0 CLOSING
0 UNKNOWN
===
===
Tue Apr 15 12:22:26 EDT 2014 -> Total SSH connections: 979
===
0 SYN_SENT
2 SYN_RECV
1 FIN_WAIT1
0 FIN_WAIT2
12 TIME_WAIT
0 CLOSED
739 CLOSE_WAIT
148 ESTABLISHED
77 LAST_ACK
0 LISTEN
0 CLOSING
0 UNKNOWN
===
Похоже, есть скачок количества подключений в CLOSE_WAIT. Во время «нормальной» работы число в CLOSE_WAIT либо 0 или очень близко к этому.
Не знаю, правильное ли это решение, но у нас оно сработало. Надеюсь, это по крайней мере укажет другим в правильном направлении, даже если не решит ее полностью.
Мы заметили, что каждый раз, когда у нас был сбой, загрузка процессора приближалась к 100%. Это, в свою очередь, произошло из-за того, что другое приложение выполняет пакетную обработку определенных файлов и использует большую часть ЦП. Мы отключили этот процесс, и до сих пор не было сбоев. Честно говоря, я не знаю, является ли это основной причиной, но это помогло нам. С тех пор ни одного сбоя.
Похоже, ваше клиентское приложение, инициирующее туннели, может не закрывать соединения должным образом после завершения операции записи.