LINUX.ORG.RU
ФорумAdmin

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


0

1

Стоит CentOS. Работают 2 интерфейса Инет - Локалка.

По непонятным причинам внешний интерфейс Инет перестает принимать входящие соединения (все, вплоть до пинга), а именно после отсутствия непродолжительного подключения к нему (скажем после окончания раб. дня когда внешние соединения пропадают).

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

Не могу понять, где искать проблему, нужна помощь опытных спецов. Возможно, что проблема в самой сетевой карте и ее надо заменить?

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

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

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

# ip r
# ip a
# iptables-save
ну и dmesg посмотри на предмет подозрительного поведения eth*.

drBatty ★★
()

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

anonymous
()
Ответ на: комментарий от drBatty

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

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

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

Revent
()
Ответ на: комментарий от chudo_baton

в

netstat -i
ошибки есть ? При не нулевых ошибках есть смысл проверить/сменить провода.

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

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

vel ★★★★★
()

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

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

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

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

NETDEV WATCHDOG: eth0: transmit timed out

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

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

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

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

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

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

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

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

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

chudo_baton
() автор топика

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

Delirium_veritas
()
Ответ на: комментарий от chudo_baton

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

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

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

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.