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

Question

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

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

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

Какие есть возможные объяснения этому поведению? Где мне искать исправление?

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

Answer 1

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

Перечислите все правила iptables

# iptables -L --line-numbers

Обратите внимание на правило принятия в цепочке INPUT , которое было настроено на прием всех соединений ssh с нашего (предыдущего) IP-адреса лица, и правило anti-bruteforce, которое отбрасывает соединения 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