ping & traceroute: Операция не позволяется

Здравствуйте. Ось: цента 6.6
Сейчас заметил, что с сервера под рутом не могу ни пропинговать, ни сделать трассировку
[console]# traceroute google.com
traceroute to google.com (173.194.113.195), 30 hops max, 60 byte packets
send: Операция не позволяется
# ping google.com
PING google.com (173.194.113.197) 56(84) bytes of data.
ping: sendmsg: Операция не позволяется
64 bytes from 173.194.113.197: icmp_seq=2 ttl=58 time=0.644 ms[/console]
Хотя вот в случае с пингом все таки дело пошло, но что это за "send: Операция не позволяется" и "ping: sendmsg: Операция не позволяется"? Раньше подобных проблем не было. Заранее спс за ответы.

PS

И периодически проскакивает
[console]# traceroute google.com
google.com: Временный сбой в разрешении имен
Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1)[/console]

"4fun" написал:

И периодически проскакивает

"4fun" написал:

send: Операция не позволяется

может в dns'е или ещё-в-каком сервисе, который участвует в разрешении имён прописана какая-то чушь вроде 0.0.0.0

Fat-Zer,
[console]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
91.211.XXX.XXX xxxxxxx.0x2a-dc.com[/console]

Где еще посмотреть я не знаю. Все дело в том, что До обеда сегодняшнего дня все работало. Настройки сервера уже не изменялись больше года. Теперь же мы имеем то, что имеем. Может ли это быть признаком, скажем, отказа сетевухи? Хотя, с домашнего пингую сервер - все норм, вроде как.

upd: Да и ведь ip по домену резолвится, но дальше движения нет.

Странно, сейчас все стало нормально, хотя я ничего не трогал, но надолго ли. В чем может быть причина?

"4fun" написал:

Где еще посмотреть я не знаю.

я подразумевал, что что-то сильно глупое в /etc/resolv.conf написано или что-то нестандартное(mdns, wins) и, гипотетически, глюкавое в hosts в /etc/nsswitch.conf...
Ещё может быть какая-то глупость в route...

"4fun" написал:

Может ли это быть признаком, скажем, отказа сетевухи?

ИМХО вряд ли...

FYI

man 2 send написал:

EACCES (для доменных сокетов UNIX, которые идентифицируются по имени пути) Нет прав на запись в файл сокета назначения или в одном из каталогов
пути запрещён поиск (см. также path_resolution(7)).

(для сокетов UDP) Попытка отправки по сетевому/широковещательному адресу, как будто это был однозначный (unicast) адрес.

man 7 ip написал:

EACCES Пользователь попытался выполнить действие, не имея на это необходимых полномочий. Примеры таких действий: посылка пакета по
широковещательному адресу без предварительной установки флага SO_BROADCAST; посылка пакета по запрещённому маршруту; изменение настроек
межсетевого экрана не имея прав суперпользователя (мандата CAP_NET_ADMIN); связывание сокета с зарезервированным портом, не имея прав
суперпользователя (мандата CAP_NET_BIND_SERVICE).

Fat-Zer написал:

FYI
[quote=man 2 send]
EACCES (для доменных сокетов UNIX, которые идентифицируются по имени пути) Нет прав на запись в файл сокета назначения или в одном из каталогов
пути запрещён поиск (см. также path_resolution(7)).

(для сокетов UDP) Попытка отправки по сетевому/широковещательному адресу, как будто это был однозначный (unicast) адрес.

man 7 ip написал:

EACCES Пользователь попытался выполнить действие, не имея на это необходимых полномочий. Примеры таких действий: посылка пакета по
широковещательному адресу без предварительной установки флага SO_BROADCAST; посылка пакета по запрещённому маршруту; изменение настроек
межсетевого экрана не имея прав суперпользователя (мандата CAP_NET_ADMIN); связывание сокета с зарезервированным портом, не имея прав
суперпользователя (мандата CAP_NET_BIND_SERVICE).

Сейчас проблема вернулась. В данный момент проблема только с трассировкой (та же ошибка), пинг проходит нормально. Плюс к этому, игровой сервер иногда не отсылает по udp ответ на запросы. Я озадачен -_-

"4fun" написал:

Я озадачен -_-

маршруты и разрешение хостов уже проверил?
[в порядке бреда]
может эти правила больно злые?

"4fun" написал:

  379  307K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           STRING match "HLBrute" ALGO name kmp TO 65535    
0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           STRING match "HLXBrute" ALGO name kmp TO 65535

Fat-Zer, эти правила уже года 2, если не больше, а проблема возникла только позавчера.

"Fat-Zer" написал:

маршруты и разрешение хостов уже проверил?

Ээ, а как?)

Плюс, хотел бы спросить, каким образом можно отклонять пакеты udp no/bad cksum? На одном форуме писали, что это можно сделать с помощью sysctl, но способ не указали. В инете инфу не нашел, хотя, быть может, не там искал. На том же форуме писали, что сейчас появился новый тип атаки на игровые сервера с помощью амплификации, в процессе которой идут как раз пакеты udp no/bad cksum. Быть может во время этого что-то где-то забивается и сетевуха не переваривает, а она у меня старая.

Как оказалось, проблема действительно из-за этой атаки. В messages довольно много записей
[console]nf_conntrack: table full, dropping packet.[/console]

Но странно, что никто не может подсказать, как отклонять те пакеты, о которых я писал выше. Просмотры темы есть, а вот ответить никто не может. Вроде же ничего сверхъестественного не спрашиваю.

"4fun" написал:

Но странно, что никто не может подсказать, как отклонять те пакеты, о которых я писал выше. Просмотры темы есть, а вот ответить никто не может. Вроде же ничего сверхъестественного не спрашиваю.

извиняй, я тутхз... жди того, кто знает...

Как оказалось, дропнуть пакет с нулевой чексуммой можно правилом
[console]iptables -I INPUT -p udp -m u32 --u32 "24&0xFFFF=0x0000" -j DROP[/console]

тыц не оно?