Я не могу подключиться к своему серверу через порт 22 или 80. Когда я запускаю netstat, я вижу, что есть несколько подключений, и все они застряли в SYN_RECV. Поиск в Google выявил в основном вопросы о DDOS. Поскольку соединений очень мало, это кажется маловероятным (хотя я нахожусь на общем хосте (slicehost)).
Что еще могло быть причиной этого?
Убедитесь, что ваш /etc/hosts.deny не поврежден. Это случилось со мной однажды и вызвало очень странные проблемы с зависшими службами netowkr.
Проверьте правила вашего брандмауэра (sudo /sbin/iptables -nvL). Вы можете настроить брандмауэр так, чтобы разрешать входящие соединения, но блокировать исходящие соединения, что приводит к зависанию входящих соединений.
Можете ли вы подключиться к этим портам на самой машине? Например, если вы вошли в систему, работает ли telnet localhost 80 Делать что-нибудь?
Что-нибудь интересное в лог-файлах вроде /var/log/secure или /var/log/messages?
Один раз я видел это раньше, это была странная проблема с синхронизацией. Соединения застревали в полуоткрытом состоянии (что означает SYN_RECV) и зависали. В результате возникли две проблемы:
Произошло то, что первоначальное соединение пришло к серверу. Он отвечает, но прежде чем он сможет это сделать, он должен выяснить MAC-адрес цели. Из-за неправильно настроенной сетевой маски он пытается ARP для IP-адреса. Затем маршрутизатор отправил proxy-arp, сообщая, что у него есть этот адрес, поэтому сервер отправил пакет SYN / ACK. Между тем, как пакет был отправлен, и когда пришло время ответить на ACK от клиента, наш балансировщик нагрузки ТАКЖЕ выдал Proxy ARP-пакет. Сервер послушно обновил свою таблицу ARP. Поэтому, когда он ответил на пакет ACK, он сделал это через совершенно другое устройство. Устройство было с отслеживанием состояния и не имело соединения для этого пакета ACK, поэтому уронил его на пол. Таким образом, соединение казалось наполовину открытым на стороне клиента.
Я не уверен, в чем была проблема, но мой хостинг-провайдер переместил мою виртуальную машину на новую машину, и проблема была решена.
В большинстве случаев виновником является брандмауэр. Делатьservice iptables stop и service ip6tables stop.
Если остановка службы не работает, выполните iptable flush.
iptables --flush