LINUX.ORG.RU
Форум — Admin  

Сервер перестал отвечать

 


0

1

Однажды утром, попытки зайти по ssh на удаленный сервер у меня не удались.
Просканировал ssh порт nmap он пишит: 

 nmap -sS -sV -p T:22 qw.hopto.org
Starting Nmap 6.25 ( http://nmap.org ) at 2013-12-09 08:58 YEKT
Nmap scan report for qw.hopto.org (x.x.x.x)
Host is up (0.0013s latency).
PORT      STATE    SERVICE VERSION
22/tcp filtered unknown
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.71 seconds
Причем на все остальные порты тоже самое. На web(apache) тоже не заходит.

Попросил человека запустит tcpdump на сервере локально. Говорит что пакеты приходят.

На сколько помню iptables там (укороченная версия) 

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0       tcp dpt:22
Тут дальше аналогично 80 порт для apache, и все остальные сервисы.
ACCEPT      all --  0.0.0.0/0            0.0.0.0/0       ctstate RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
В таблице nat. В PREROUTING проброшено несколько портов (DNAT). А в POSTROUTING стоит MASQUERADE для его локально сети. И вроде все. ничего больше нет.

В чем может быть проблема ?

★

Последнее исправление: demsi (всего исправлений: 2)
← Argument list too long - workaround?
Проблемы с OpenVPN извне →

На сколько помню iptables там (укороченная версия)

Если там есть человек, пусть почитает вывод iptables-save, может там совсем другие правила уже, чего попусту гадать.

mky ★★★★★
()

сделайте с сервера ssh -R 2222:localhost:22 на какой-то ещё сервер и с этого сервера сходите ssh -p 2222 localhost - это поможет исключить часть проблем с iptables.

pianolender ★★★
()
Ответ на: комментарий от mky

Если там есть человек, пусть почитает вывод iptables-save, может там совсем другие правила уже, чего попусту гадать.

Я не гадаю, кроме меня, этот сервак никто не админит. Человек сделал вывод таблиц в файл и отослал мне.

Я уходил на долго, сейчас пришел. Проблема ушла. Не знаю по чему. Позвонил, спросил говорят что никто срвак не трогал.

Дело в том что я уже давно заметил эти странности. Бывает хочешь зайти на сервер, а он не работает. Потом через 5 минут заработал. Ну я все время думал что это дело со связью что-то. А вот сейчас доступа к серверу не было очень долго. Причем ни один сетевой демон не отвечал на запросы.
В общем странно все это. Раньше все работало нормально, но мне кажется это начало происходить, после того, когда меня попросили установить туда сервер teamspeak.

Может ли быть, что это как-то связано? Не знаю

demsi ★
() автор топика
Ответ на: комментарий от demsi

Я бы больше грешил на глюки провайдерского оборудования. Они бывают разные, глюки эти, рубится могут не все пакеты, а только определённые или модифицироваться содержимое. Хорошо бы получить записанный в файл дамп пакетов в это время, чтобы было видно что приходят не просто пакеты, а именно SYN-пакеты и что ответные с сервера не уходят. Тогда это проблемы сервера.

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

mky ★★★★★
()
Ответ на: комментарий от mky

Блин как жалко что проблема куда-то ушла. Хотелось бы задетектить её снова. Вот только когда были такие глюки, пинг с сервера проходил. А на сервер нет. Ну в следущий раз с tcpdump ом постараюсь по подробнее.

demsi ★
() автор топика
Ответ на: комментарий от demsi

Ну, если сервер не очень нагруженный, то можно запустить tcpdump постоянно на запись в файл с фильтром, чтобы дампил пакеты с определённым ip-адресом/протоколом/портом.

mky ★★★★★
()
Ответ на: комментарий от mky

Опять на пару секунд появилась проблема снова.
На сервере tcpdump говорит пришло 4 пакета SYN на ssh. Ответы не высланы.
Самое интересное пинг с сервера на мой комп выдает: 

connect: No buffer space available
traceroute до моего компа с сервера, тоже самое только на русском. 
connect: Недостаточно буферного пространства.
На http://www.ru и google.ru и 8.8.8.8 и шлюз провайдера пинг и трассировка с него проходили в этот момент нормально.

Это все очень странно.

demsi ★
() автор топика
Ответ на: комментарий от mky

dmesg | grep -i arp - пусто

Зато смотрите что говорит tcpdump -n arp - pastebin

Куча запросов от абсолютно разных ип адресов да и мак адресов тоже 

17:14:39.183407 ARP, Request who-has x.x.x.x (00:24:b2:dc:0f:0d) tell x.x.x.x, length 46
17:14:39.186998 ARP, Request who-has x.x.x.x (14:da:e9:0f:2b:39) tell x.x.x.x, length 46
17:14:39.187175 ARP, Request who-has x.x.x.x (f4:6d:04:a1:04:20) tell x.x.x.x, length 46
17:14:39.192871 ARP, Request who-has x.x.x.x (c8:0a:a9:4c:ea:b1) tell x.x.x.x, length 46
17:14:39.198706 ARP, Request who-has x.x.x.x (14:d6:4d:77:fc:95) tell x.x.x.x, length 46
17:14:39.203053 ARP, Request who-has x.x.x.x (d8:eb:97:20:1e:96) tell x.x.x.x, length 46
17:14:39.214031 ARP, Request who-has x.x.x.x (70:71:bc:78:11:82) tell x.x.x.x, length 46
17:14:39.215064 ARP, Request who-has x.x.x.x (f4:6d:04:a0:da:03) tell x.x.x.x, length 46
17:14:39.216743 ARP, Request who-has x.x.x.x (90:94:e4:f3:4f:33) tell x.x.x.x, length 46
17:14:39.218833 ARP, Request who-has x.x.x.x (20:cf:30:88:7b:e5) tell x.x.x.x, length 46
17:14:39.221466 ARP, Request who-has x.x.x.x (00:23:54:51:45:51) tell x.x.x.x, length 46
17:14:39.221853 ARP, Request who-has x.x.x.x (34:08:04:d6:1f:33) tell x.x.x.x, length 46
17:14:39.222104 ARP, Request who-has x.x.x.x (90:2b:34:a8:e6:7d) tell x.x.x.x, length 46
17:14:39.222830 ARP, Request who-has x.x.x.x (f4:6d:04:a1:26:aa) tell x.x.x.x, length 46
17:14:39.223849 ARP, Request who-has x.x.x.x (90:94:e4:f3:64:51) tell x.x.x.x, length 46
17:14:39.224540 ARP, Request who-has x.x.x.x (c8:6c:87:41:39:5a) tell x.x.x.x, length 46
17:14:39.226483 ARP, Request who-has x.x.x.x (2c:ab:25:3c:21:3a) tell x.x.x.x, length 46
17:14:39.227270 ARP, Request who-has x.x.x.x (00:26:9e:45:65:0d) tell x.x.x.x, length 46
17:14:39.232558 ARP, Request who-has x.x.x.x (bc:f6:85:49:d4:87) tell x.x.x.x, length 46
17:14:39.236247 ARP, Request who-has x.x.x.x (f4:6d:04:7d:50:fb) tell x.x.x.x, length 46
17:14:39.239457 ARP, Request who-has x.x.x.x (c8:d3:a3:4b:4b:5b) tell x.x.x.x, length 46
17:14:39.244185 ARP, Request who-has x.x.x.x (40:61:86:11:f0:c1) tell x.x.x.x, length 46
17:14:39.244228 ARP, Request who-has x.x.x.x (ec:43:f6:01:ec:0d) tell x.x.x.x, length 46
17:14:39.244719 ARP, Request who-has x.x.x.x (40:61:86:11:f0:c1) tell x.x.x.x, length 46
17:14:39.246262 ARP, Request who-has x.x.x.x (60:a4:4c:84:65:60) tell x.x.x.x, length 46
17:14:39.257610 ARP, Request who-has x.x.x.x (ac:f1:df:d1:81:86) tell x.x.x.x, length 46
17:14:39.258616 ARP, Request who-has x.x.x.x (58:6d:8f:48:c0:e4) tell x.x.x.x, length 46
17:14:39.259807 ARP, Request who-has x.x.x.x (20:cf:30:89:06:f1) tell x.x.x.x, length 46
17:14:39.261670 ARP, Request who-has x.x.x.x (ac:f1:df:cf:e2:a1) tell x.x.x.x, length 46
17:14:39.265066 ARP, Request who-has x.x.x.x (fc:f5:28:48:c0:89) tell x.x.x.x, length 46
17:14:39.268315 ARP, Request who-has x.x.x.x (10:bf:48:1b:08:70) tell x.x.x.x, length 46
17:14:39.274785 ARP, Request who-has x.x.x.x (b0:b2:dc:a8:11:7b) tell x.x.x.x, length 46
17:14:39.276282 ARP, Request who-has x.x.x.x (d0:b3:3f:46:a5:a2) tell x.x.x.x, length 46
там где tell x.x.x.x, это ип адрес шлюза провайдера.

Надеюсь ничего страшного что я обработал все sed дабы скрыть ип адреса ?

demsi ★
() автор топика
Последнее исправление: demsi (всего исправлений: 3)
Ответ на: комментарий от mky

А еще по ssh 

17:10:20.697147 IP x.x.x.x.33206 > x.x.x.x.22: Flags [S], seq 3226476769, win 29200, options [mss 1460,sackOK,TS val 5777690 ecr 0,nop,wscale 7], length 0
17:10:21.695310 IP x.x.x.x.33206 > x.x.x.x.22: Flags [S], seq 3226476769, win 29200, options [mss 1460,sackOK,TS val 5777940 ecr 0,nop,wscale 7], length 0
17:10:23.699312 IP x.x.x.x.33206 > x.x.x.x.22: Flags [S], seq 3226476769, win 29200, options [mss 1460,sackOK,TS val 5778441 ecr 0,nop,wscale 7], length 0
17:10:27.711336 IP x.x.x.x.33206 > x.x.x.x.22: Flags [S], seq 3226476769, win 29200, options [mss 1460,sackOK,TS val 5779444 ecr 0,nop,wscale 7], length 0
17:10:35.731290 IP x.x.x.x.33206 > x.x.x.x.22: Flags [S], seq 3226476769, win 29200, options [mss 1460,sackOK,TS val 5781449 ecr 0,nop,wscale 7], length 0
Как видно пакеты SYN на сервер пришли с нулевой длинной данных. Это не странно ?

demsi ★
() автор топика
Ответ на: комментарий от demsi

Syn-пакеты нормальные. Нулевая длина относится к данным внутри tcp-пакета, а не к самому пакету.

Сообщения про переполнение arp-таблицы должны выглядеть как-то так: 

ipv4: Neighbour table overflow.

Проверьте, что у вас правильно прописан маршрут по умолчанию, именно через адрес шлюза провайдера, а не через ip-адрес на eth0 интерфейсе.

Или этот флуд идёт от провайдера, тогда народ пробует увеличивать gc_thresh[1-3], погуглите ″gc_thresh1″.

mky ★★★★★
()
Ответ на: комментарий от mky

Сообщения про переполнение arp-таблицы должны выглядеть как-то так:

Ну да, вы правы 

dmesg | grep "Neighbour table overflow" | wc -l
2230
Маршрут по умолчанию идет через шлюз провайдера.

Хотелось бы у вас узнать (вы скорее всего лучше tcpdump знаете). Как понять запись: 

17:14:35.137318 ARP, Request who-has 1.1.2.2 tell 1.1.1.1, length 46
где 1.1.1.1 - шлюз провайдера
Я не могу понять, кто кому шлет arp запрос, шлюз или 1.1.2.2 ?
В wireshark - понятно. Там написано source - мак адрес шлюза, destination мак адрес широковещательный ( т.е. ff:ff:ff:ff:ff:ff).
В tcpdump к сожалению, не понятно кто кому, что шлет.

В общем это все шлюз провайдера рассылает arp запросы. Это нормальное поведение ? К интернету сервер подключается просто получая адрес по dhcp от шлюза провайдера. При чем этот адрес, как говорится белый внешний.

demsi ★
() автор топика
Ответ на: комментарий от demsi

Как написано, так всё и есть, шлюз провайдера 1.1.1.1 ищет 1.1.2.2. Не знаю, глюк или какие-то хирожопые настройки оборудования провайдера. Обычно arp-запросы в одной подсети, то есть у меня домашний провайдер навешал несколько подсдетей, одну «белую» и пару-тройку «серых» 172.x.x.x. Его cisco переодически пробегает arp-запросами по всем подсетям, но серые подсети опрашивает с 172.x.x.x адресов, а белую — с белого адреса.

Но ЕМНИП, arp-запросы не должны вести к поялению записей/переполнению arp-таблицы, проблему должны создавать широковещательные анонсы/ответы. Вобще посмотрите содержимое arp-таблицы (команда ″ip neigh″). Эту таблицу забивает записями, относящимися к интерфейсу к провайдеру?

У tcpdump есть опция ″-e″, чтобы показывало MAC-адреса, кроме того, можно записать в файл и, ЕМНИП, wireshark его прочитает, или можно установить на сервер wireshark.

mky ★★★★★
()
Ответ на: комментарий от mky

Но ЕМНИП, arp-запросы не должны вести к поялению записей/переполнению arp-таблицы, проблему должны создавать широковещательные анонсы/ответы. Вобще посмотрите содержимое arp-таблицы (команда ″ip neigh″). Эту таблицу забивает записями, относящимися к интерфейсу к провайдеру?

В том и проблема что при выводе ошибок Neighbour table overflow В таблице находится только одна запись. 

tail /var/log/syslog
Dec 14 08:42:50 kernel: Neighbour table overflow

date
Сбт Дек 14 08:42:56 2013

arp -an | wc -l
1

demsi ★
() автор топика
Ответ на: комментарий от mky

Еще появляется надпись в логах: 

__ratelimit: 110 callbacks suppressed

demsi ★
() автор топика
Последнее исправление: demsi (всего исправлений: 1)
Ответ на: комментарий от mky

Увеличил память для таблицы arp. 

echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
А было
128
512
1024
Соотвественно
Пока помогает. Но все равно, причина проблемы не ясна.
А еще хотел спросить, где можно найти документации по всем подобным параметрам из procfs ?
Единственное что я знаю и использовал это был ip_forward. От вас узнал про gc_thresh, и заинтересоваля, где же хранится описание подобных параметров.

demsi ★
() автор топика
Ответ на: комментарий от demsi

Но все равно, причина проблемы не ясна.

Это надо ковырять исходники ядра, пишут, что вроде как ядро может резервировать место в arp-таблице просто увидев чужой arp-запрос.

где можно найти документации по всем подобным параметрам из procfs ?

С этим туго, в том плане, что всё разбросано по разным местам. По поводу gc_thresh есть ″man 7 arp″, по /proc в целом есть ″man proc″. И в исходниках ядра есть текстовые файлы: ″Documentation/filesystems/proc.txt″ в общем про /proc и по сети ″Documentation/networking/ip-sysctl.txt″.

Если есть желание конкретно загрузиться, можно посмотреть все файлы/каталоги в /proc/sys/, для каждого каталога грепая по имени proc-файлов искать в ″/usr/src/linux/Documentation″ текстовый документ с описанием. Причём этот каталог лучше взять от самого свежего ядра. Запоминать всё не нужно, просто создать общее представление.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Argument list too long - workaround?
Admin
Проблемы с OpenVPN извне →