Назад | Перейти на главную страницу

Обходные пути для возможной проблемы TIME_WAIT, препятствующей восстановлению сломанных туннелей SSH?

Не собираясь делать кросс-посты, отправив этот вопрос в список OpenSSH на SecurityFocus, я заметил, что трафик в этом списке довольно низкий (предыдущий пост был примерно 5 месяцев назад). При этом я решил сделать репост здесь, поскольку проблема, вероятно, привлечет больше внимания (и у нее будет больше шансов быть полезной для других, если ответят):

Проблема: у меня есть обратный SSH-туннель от внутренней машины к хосту в моей DMZ, который настроен на запуск при загрузке системы и перезапуск в случае сбоя туннеля. Однако, когда туннель прерывается (например, из-за сбоя сети), он не может быть восстановлен из-за того, что порт на хосте DMZ используется. Из того, что я читал в архивах списков рассылки OpenSSH и в других местах, похоже, что это связано с тем, что порт находится в состоянии TIME_WAIT. Это нормально: я могу добавить инструкцию сна в скрипт, который устанавливает туннель. Однако это приводит к двум вопросам:

1) Any idea how to determine what the TIME_WAIT interval is defined as on a particular Linux (or other) system? While I could just sleep for 5 minutes and be fine, it would be good to shave off as much time as possible.

2) While OpenSSH doesn't appear to support the "ClearAllForwardings" option, is there similar functionality whereby an auth'd connection can automatically teardown and recreate an existing connection it had previously established?

A long sleep would probably be "good enough" but I'd prefer to handle the TIME_WAIT condition in a more efficient manner if possible.

I appreciate any guidance or suggestions!

Я бы подумал, что вы можете поиграть с различными настройками SSH, такими как TCPKeepAlive, ServerAliveInterval, ServerAliveCountMax и т. Д., Чтобы настроить, где, если соединение обрывается, оно убьет все. У меня аналогичная настройка, и я внес много изменений в SSHD и SSH с обеих сторон, чтобы они соответствовали тому, что я хочу. Затем у меня есть задание cron, которое запускается каждые 5 минут и перезапускает туннель, если мне нужно.

#!/bin/bash
if ps aux | grep "ssh -fnNTx" | grep -v "grep"
then
echo "Already Running"
else
echo "Starting now"
ssh -fnNTx -L 1514:127.0.0.1:514 user1@X.X.X.X
fi

До сих пор это решение меня устраивало. Вы также можете настроить какой-либо тип проверки Nagios или другой скрипт, чтобы увидеть, открыт ли туннель, и, если нет, выполнить уничтожение этого pid, чтобы он мог перезапуститься.

Редактировать:

Предыдущая статья, в которой много говорится о проблемах с TIME_WAIT. Как принудительно закрыть сокет в TIME_WAIT?

SSHD должен установить SO_REUSEADDR, позволяя новому экземпляру связываться, даже если у предыдущего экземпляра все еще есть соединения в состоянии TIME_WAIT. Либо у вас есть SSHD с ошибками, либо у вас есть какой-то параметр конфигурации, который запрещает это поведение (например, если вы отключен X11UseLocalHost).