1 (03.01.2015 18:41:50 отредактировано 4fun)

Здравствуйте. Ось: цента 6.6
Сейчас заметил, что с сервера под рутом не могу ни пропинговать, ни сделать трассировку

 Консоль:
# 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

Хотя вот в случае с пингом все таки дело пошло, но что это за "send: Операция не позволяется" и "ping: sendmsg: Операция не позволяется"? Раньше подобных проблем не было. Заранее спс за ответы.

PS

+ Правила iptables

 Консоль:
# iptables -L -n -v
Chain INPUT (policy ACCEPT 23M packets, 1535M bytes)
pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       91.211.XXX.XXX       0.0.0.0/0           tcp dpt:ZZZZ
  475 33345 ACCEPT     tcp  --  *      *       91.211.YYY.YY        0.0.0.0/0           tcp dpt:ZZZZ
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:ZZZZ
  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

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 24M packets, 4266M bytes)
pkts bytes target     prot opt in     out     source               destination 

2

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

 Консоль:
# traceroute google.com
google.com: Временный сбой в разрешении имен
Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1)

3

4fun пишет:

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

4fun пишет:

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

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

95% процентов проблем находятся между клавиатурой и стулом.

4 (03.01.2015 19:52:47 отредактировано 4fun)

Fat-Zer,

 Консоль:
# 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

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

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

5

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

6 (04.01.2015 00:39:10 отредактировано Fat-Zer)

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).

95% процентов проблем находятся между клавиатурой и стулом.

7

Fat-Zer пишет:

FYI

man 2 send пишет:

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

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

man 7 ip пишет:

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

Ну, это следствия, так сказать. А пути решения какие?

8 (04.01.2015 21:38:15 отредактировано 4fun)

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

9 (05.01.2015 03:02:00 отредактировано Fat-Zer)

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

95% процентов проблем находятся между клавиатурой и стулом.

10

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

Fat-Zer пишет:

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

Ээ, а как?)

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

11

Как оказалось, проблема действительно из-за этой атаки. В messages довольно много записей

 Консоль:
nf_conntrack: table full, dropping packet.

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

12

4fun пишет:

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

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

95% процентов проблем находятся между клавиатурой и стулом.

13

Как оказалось, дропнуть пакет с нулевой чексуммой можно правилом

 Консоль:
iptables -I INPUT -p udp -m u32 --u32 "24&0xFFFF=0x0000" -j DROP

14

тыц не оно?

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22