Тайм-аут соединения SSH только на определенных клиентах

У меня есть сервер, на котором активно около 100 SSH-туннелей с клиентских серверов в Канаде и США. Мы используем то же устройство, на котором выполняется пользовательская сборка Ubuntu, и загружаем его на каждый клиентский сервер, который подключается к серверу. Недавно я попытался настроить некоторые из этих клиентских серверов и получаю тайм-аут соединения при попытке подключиться к главному серверу с этих клиентских серверов.

Вот некоторые важные шаги по отладке, которые я предпринял, и их результаты:

  1. Клиентский сервер получает тайм-аут при попытке подключения к главному серверу, даже если он может пропинговать сервер.
  2. При попытке подключиться к порту 22 через telnet, время ожидания соединения истекает вместо получения подтверждения SSH
  3. Я могу использовать SSH на любой другой машине с этого клиентского сервера, кроме основного.
  4. Другие машины могут подключаться по SSH к главному серверу, даже с тем же IP-адресом, что и клиентские серверы.
  5. Каждый клиентский сервер имеет ту же сборку ОС, что и другие клиентские серверы.
  6. Существует около 100 активных подключений с других клиентских серверов, развернутых в настоящее время с использованием той же конфигурации, но только эти новые испытывают проблему
  7. Я увеличил максимальное количество попыток подключения SSH (MaxStartups), а также максимальное количество подключений TCP-сокетов (net.core.somaxconn) до 2000 и 65535 соответственно, и это не улучшило ситуацию

Я застрял и должен выяснить, почему это происходит. Любая помощь будет оценена. Спасибо!

Источник

1 ответ

После большого количества исследований и поисков в Google, я смог найти причину и, в конечном итоге, исправить. После исключения проблем с сетью и DNS я остался только с протоколом. Поскольку Ping работал, а telnet к порту 1 - нет, я знал, что это не может быть проблемой порта. После тестирования трафика с использованием UDP и TCP оказалось, что TCP был единственным протоколом, в котором возникла проблема.

Я побежал tcpdump чтобы проверить пакеты, которыми обменивались, и я сразу заметил, что только исходный пакет SYN отправлялся от клиента к серверу, и ACK не возвращался. К сожалению, первопричины пока не найдено.

Запустив netstat -s до и после попытки нескольких соединений ssh ​​в течение нескольких испытаний единственное значение, которое было отключено, было "Пассивное соединение отклонено из-за отметки времени". Я нашел эту статью (на японском языке), которая была связана с этой проблемой, и предложил связь с tcp_tw_recycle в среде NAT. В результате был сделан вывод об отключении tcp_tw_recycle, вследствие чего число открытых TCP-соединений удвоилось, и мы смогли решить эту проблему. В этом ответе ServerFault подробно обсуждаются его последствия.

Надеюсь, этот ответ окажется полезным для кого-то еще, кто в конечном итоге имеет дело с этим крайним случаем. Кроме того, есть ли у кого-нибудь дополнительные предложения / предупреждения, связанные с этим решением?

Источник
Другие вопросы по тегам