В офисе у нас есть интересная ситуация: после подключения (даже если это просто обновление веб-страницы) с любого компьютера к нашему тест-серверу (размещенному на AWS) другой компьютер не сможет больше подключиться в течение некоторого времени ( около 30 секунд).
Первый компьютер по-прежнему сможет подключиться, и все уже открытые подключения со второго по-прежнему будут работать (например, SSH).
Это происходит только тогда, когда оба компьютера находятся на одном сетевом / внешнем IP-адресе. Например, если второй компьютер будет использовать VPN - он сможет подключиться.
Очевидно, это далеко не оптимально.
Я пытаюсь понять, что случилось. Таблица правил Iptables полностью пуста, за исключением одного правила, которое я добавил для регистрации входящих подключений к SSH (для целей отладки):
iptables -I INPUT -p tcp --dport 22 --syn -j LOG --log-prefix "22 SSH: "
Это показывает, что, хотя второй компьютер не может подключиться к SSH, пакеты все еще достигают сервера (и регистрируются iptables с такими данными, как: «LEN = 48 TOS = 0x00 PREC = 0x00 TTL = 49 ID = 18889 DF PROTO. = TCP SPT = 54750 DPT = 22 WINDOW = 65535 RES = 0x00 SYN URGP = 0 ").
Что еще я могу проверить, чтобы попытаться найти причину такого странного поведения?
Нашел. sysctl tcp_tw_recycle был установлен в 1. Что, очевидно, вызывает проблемы с клиентами, находящимися за NAT (Ссылка: https://stackoverflow.com/questions/8893888/dropping-of-connections-with-tcp-tw-recycle )