☰

Запросы на подключение зависают с SYN_SENT после нескольких попыток

tag-icon • tag-icon networking ssh
Запросы на подключение зависают с SYN_SENT после нескольких попыток

Мы переехали в офис и настроили инфраструктуру LAN/WAN на новом месте.

Когда я инициирую SSH-подключения к своему серверу (который находится в облаке, а не в локальной сети), все работает нормально для первых 3 или 4 запросов с короткими интервалами (например, 4 вызова в течение 5 секунд), дальнейшие соединения зависают в статусе SYN_SENT. Все последующие запросы зависают в статусе SYN_SENT до того, что выглядит как тайм-аут. После этого все снова заработает несколько раз.

Никаких изменений на сервере не было, и разные локальные клиенты ведут себя таким образом. Так что я предполагаю, что разница заключается в ИТ-инфраструктуре, а не в двух конечных точках.

Какие возможны объяснения такого поведения? Где искать решение?

Мы используем брандмауэр Zyxel ZyWall, настройки которого пришлось сбросить. Есть ли у него какой-либо фильтр, который мог бы объяснить такое поведение?

решение1

Правила iptables на сервере имели цепочку правил "anti ssh bruteforce", которая использует модуль "recent" для разрыва соединений после 4 попыток в течение 1 минуты. Это правило имело исключение в цепочке INPUT, чтобы разрешить все ssh с нашего face IP. Когда мы переехали, face IP изменился, и правило пришлось адаптировать. Для справки, вот как я это сделал

Список всех правил iptables

# iptables -L --line-numbers

Обратите внимание на правило приема в INPUTцепочке, которое было установлено для приема всех SSH-подключений с нашего (предыдущего) IP-адреса Face, и правило защиты от подбора паролей, которое сбрасывает SSH-подключения после нескольких попыток в SSH_CHECKцепочке:

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
...
14   ACCEPT     tcp  --  old.myISP.com      anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num  target     prot opt source               destination
...
3    DROP       all  --  anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source

Редактирование правил в/etc/iptables.rules

Изменять

-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT

к

-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT

где 111.222.33.44 — новый IP-адрес лица. И читаем в адаптированных правилах:

 # iptables-restore < /etc/iptables.rules

Связанный контент