Загадка в сетевом интерфейсе

А логи кто показывать будет?

покажу, что вытащить

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

ИМХО наверное так и есть.

Но всё-же покажи

# ip r
# ip a
# iptables-save

у меня такое было, когда на внешний интерфейс инет приходил с adsl модема. замечу, что соединение было не по pppoe, а напрямую выдавался статический ip адрес в карту eth0 причем проблема была на двух разных шлюзах, на которых стояла Slackware 13.37 решил проблему так: на шлюзе в cron забил задание на пинг 8,8,8,8 раз в 2 мин.

ip r

ххх.ххх.хх.ххх/30 dev eth0 proto kernel scope link src ххх.ххх.ххх.ххх

192.168.0.0/24 dev eth1 proto kernel scope link src

192.168.0.101

169.254.0.0/16 dev eth1 scope link metric 1002

169.254.0.0/16 dev eth0 scope link metric 1003

default via xxx.xxx.xxx.xxx dev eth0

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state

UNKNOWN

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc

pfifo_fast state UNKNOWN qlen 1000

link/ether 84:c9:b2:70:19:0f brd ff:ff:ff:ff:ff:ff

inet 192.168.0.101/24 brd 192.168.0.255 scope global eth1

inet6 fe80::86c9:b2ff:fe70:190f/64 scope link

valid_lft forever preferred_lft forever

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc

pfifo_fast state UNKNOWN qlen 1000

link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

inet xxx.xxx.xxx.xxx/30 brd xxx.xxx.xxx.xxx scope global

eth0

inet6 fe80::250:22ff:fe89:3596/64 scope link

valid_lft forever preferred_lft forever

iptables-save

*nat

:PREROUTING ACCEPT [721624:65073745]

:POSTROUTING ACCEPT [4278:254659]

:OUTPUT ACCEPT [4278:254659]

-A PREROUTING -i eth0 -p tcp -m tcp --dport xxxx -j DNAT

--to-destination 192.168.0.1:xxxx

-A POSTROUTING -d 192.168.0.1/32 -p tcp -m tcp --dport xxxx -j

SNAT --to-source 192.168.0.101

COMMIT

# Completed on Fri Jul 12 11:12:14 2013

# Generated by iptables-save v1.4.7 on Fri Jul 12 11:12:14 2013

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [37428:27178473]

:OUTPUT ACCEPT [3890381:7213644079]

:fail2ban-SSH - [0:0]

:fail2ban-VSFTPD - [0:0]

:fail2ban-recidive - [0:0]

-A INPUT -p tcp -j fail2ban-recidive

-A INPUT -p tcp -m tcp --dport 21 -j fail2ban-VSFTPD

-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m tcp --dport xxxx -j

ACCEPT

-A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport xx -j ACCEPT

-A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport xxxx -j ACCEPT

-A INPUT -s 192.168.0.0/24 -p udp -m udp --dport xxxx -j ACCEPT

-A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport xxxx -j ACCEPT

-A INPUT -p tcp -m tcp --dport xxxx -j ACCEPT

-A INPUT -p udp -m udp --dport xxxx -j ACCEPT

-A INPUT -p tcp -m tcp --dport xxxx -j ACCEPT

-A INPUT -p udp -m udp --dport xxxx -j ACCEPT

-A INPUT -p tcp -m tcp --dport xxxx -j ACCEPT

-A INPUT -p tcp -m tcp --dport xxxx -j ACCEPT

-A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport xxxx -j ACCEPT

-A INPUT -s 192.168.0.0/24 -p udp -m udp --dport xxxx -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-port-unreachable

-A fail2ban-SSH -j RETURN

-A fail2ban-VSFTPD -j RETURN

-A fail2ban-recidive -j RETURN

COMMIT

ну как такую портянку то читать? оформи все в

Версия centos какая? Что за карточка (чипсет)?

CentOS release 6.4 (Final)

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

в

netstat -i

Машина старая ? Может просто железо дохнет...

в dmesg нет сообщений об ошибках c сетью ?

Подключаюсь к проблемному компьютеру по ssh через внутренний интерфейс (работает без проблем), предварительно запускаю пинг на его внешний интерфейс

Подключаетесь из локальной сети? А пинг на внешний интерфейс (внешний ip-адрес) запускаете снаружи или из локальной сети?

снаружи, с другого Интернет канала

Хорошо. В этом топике вас дважды спрашивали про сообщения в dmesg. Присоединяюсь к этому вопросу. Есть ли в dmesg (это команда) ругательства наподобие:

NETDEV WATCHDOG: eth0: transmit timed out

Или вобще хоть какие-то сообщения о eth0 после загрузки системы.

Если в dmesg всё чисто, попробуйте запустить в фоне tcpdump на перехват icmp пакетов с записью в файл и воспроизвести эту ситуацию, когда ping'и не проходят. Потом можно будет посмотреть, доходят ли ping'и до ядра (до tcpdump).

как ни странно,

повторил решение проблемы, 2-ое суток проблем с внешним интерфейсом нету, все соединения принимаются

пинг поставил 1 раз в 10 минут.

в dmesg пока, что проблем не вижу с tcpdump не эксперементировал, не хватает времени

есть ли такое понятие в linux спящий режим, скажем для сетевой карты?

У меня такая гадость была на гигабитной сетевухе rtl8138 на ядрах 2.6.непомню. Решилось дровиной (модулем ядра) от Realtek. Кроме описаной ситуации был ещё один интересный баг. При наличии одного подключения скорость копирования по сети была ниже 10 Мбит. При запуске пинга с соседней машины скорость взлетала до номинального значения.

Спящий режим (hibernate) в Линуксе есть, но это не ваш случай. Отключение сетевой карточки, тем более на CentOS, не встречал. Да ещё такое странное отключение, что интерфейс активизируется при наличии tcp-подключения на другом интерфейсе. Ведь ввод пароля это ещё не наличие активной пользовательской сессии...

Как вариант, можно ведь временно подключить карточку в другой свич и там сделать локальную сеть с тем же адресом ххх.ххх.хх.ххх/30, чтобы потестировать.

Ну и можно попробовать переключить карточку в 10 Мбит Half-duplex.