realtek 8169 (в Debian нет связи с некоторыми узлами)

IMB · Сообщение **IMB** » 30.04.2008 16:01

Доброго дня!
Имеется одноранговая сеть Windows-машин. К центральному свитчу подсоединены Linux-сервера - proxy, mail и database на DebianEtch и Windows-сервера. Пользователи подсоединены к этажным свитчам, которые соединены с центральным. На всех машинах прописаны статические адреса.
На одну из машин, параллельно с WindowsXP, установили DebianEtch.
Настройки сети в Debian, фаервол не настраивался и применяется политика ACCEPT:

Код: Выделить всё

allow-hotplug eth0
iface eth0 inet static
    address 192.168.0.132
    netmask 255.255.255.0
    network 192.168.0.0
    broadcast 192.168.0.255
    gateway 192.168.0.250

Настройка сети в WindowsXP, фаервол выключен:

Код: Выделить всё

Описание  . . . . . . . . . . . . : Realtek RTL8169/8110
Физический адрес. . . . . . . . . : 00-0F-EA-CE-B1-28
Dhcp включен. . . . . . . . . . . : нет
IP-адрес  . . . . . . . . . . . . : 192.168.0.132
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.0.250

Выход в интернет через proxy-сервер без авторизации.
Проблема в том что в Debian постоянно нет связи с proxy и mail-сервером. В тоже время есть связь с database-сервером, центральным и этажными свитчами, а также с Windows-серверами. Из под Windows, с этой же машины, связь со всеми серверами есть постоянно.
В Debian связь проверялась ping-ом и доступом в интернет, в Windows - ping, ssh на сервера и доступ в интернет.
Как я рассуждаю:
в Windows связь есть со всеми узлами, значит сетевые карточки на локальной и удаленных машинах в порядке, сетевые кабели в порядке, фаерволы нигде не блокируют
в Debian нет связи с proxy и mail-сервером - проблема или локально или удаленно, так как через эти сервера выходит весь офис, то о их проблемах я бы узнал сразу - об отсутствии выхода в Интернет или проблемах с почтой сразу сообщили бы, значит, скорее всего, проблема локально, но в чем, или из-за чего, я понять не могу, т.к. связь с частью узлов есть.
В чем может быть причина?
Спасибо.

IMB · Сообщение **IMB** » 02.05.2008 14:21

Доброго дня!
Привожу дополнительную информацию:
proxy-server (DebianEtch), снято из Windows по ssh:

Код: Выделить всё

lspci -vvv
...............................................
01:01.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
        Subsystem: Intel Corporation PRO/1000 GT Desktop Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (63750ns min), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 50
        Region 0: Memory at cdda0000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at cdd80000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at 9800 [size=64]
        Expansion ROM at 50000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=1
                Status: Dev=00:00.0 64bit- 133MHz- SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-

Код: Выделить всё

ip a
eth4: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0e:0c:b7:54:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.250/24 brd 192.168.0.255 scope global eth4
    inet6 fe80::20e:cff:feb7:54ff/64 scope link
       valid_lft forever preferred_lft forever

Код: Выделить всё

ifconfig
eth4      Link encap:Ethernet  HWaddr 00:0E:0C:B7:54:FF
          inet addr:192.168.0.250  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:cff:feb7:54ff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:36290697 errors:290 dropped:0 overruns:0 frame:290
          TX packets:35365062 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2079088939 (1.9 GiB)  TX bytes:2722927691 (2.5 GiB)
          Base address:0x9800 Memory:cdda0000-cddc0000

Код: Выделить всё

ifconfig -s eth4
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR   TX-OK TX-ERR TX-DRP TX-OVR Flg
eth4   1500 0  36291506    290      0      0 35365354      0      0      0 BMRU

локальной машине:

Код: Выделить всё

lspci -vvv
.................................
02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
    Subsystem: Giga-byte Technology GA-8I915ME-G Mainboard
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
    Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
    Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 128 bytes
    Interrupt: pin A routed to IRQ 201
    Region 0: I/O ports at a400 [size=256]
    Region 1: Memory at fb001000 (32-bit, non-prefetchable) [size=256]
    [virtual] Expansion ROM at 50010000 [disabled] [size=64K]
    Capabilities: [dc] Power Management version 2
        Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Проверка доступности различных хостов из Debian:
локальный интерфейс

Код: Выделить всё

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.008 ms

--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.008/0.014/0.020/0.006 ms

центральный свитч

Код: Выделить всё

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=11.5 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=2.14 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=2.13 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=2.13 ms

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3013ms
rtt min/avg/max/mdev = 2.137/4.501/11.590/4.093 ms

database-server (DebianEtch)

Код: Выделить всё

PING 192.168.0.253 (192.168.0.253) 56(84) bytes of data.
64 bytes from 192.168.0.253: icmp_seq=1 ttl=64 time=6.80 ms
64 bytes from 192.168.0.253: icmp_seq=2 ttl=64 time=0.288 ms
64 bytes from 192.168.0.253: icmp_seq=3 ttl=64 time=0.286 ms
64 bytes from 192.168.0.253: icmp_seq=4 ttl=64 time=0.285 ms

--- 192.168.0.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3010ms
rtt min/avg/max/mdev = 0.285/1.915/6.801/2.820 ms

Windows-server (WindowsServer2003Standart R2)

Код: Выделить всё

PING 192.168.0.251 (192.168.0.251) 56(84) bytes of data.
64 bytes from 192.168.0.251: icmp_seq=1 ttl=128 time=1.20 ms
64 bytes from 192.168.0.251: icmp_seq=2 ttl=128 time=0.279 ms
64 bytes from 192.168.0.251: icmp_seq=3 ttl=128 time=0.264 ms
64 bytes from 192.168.0.251: icmp_seq=4 ttl=128 time=0.260 ms
64 bytes from 192.168.0.251: icmp_seq=5 ttl=128 time=0.262 ms
64 bytes from 192.168.0.251: icmp_seq=6 ttl=128 time=0.267 ms

--- 192.168.0.251 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5000ms
rtt min/avg/max/mdev = 0.260/0.423/1.207/0.350 ms

этажный пользовательский свитч

Код: Выделить всё

PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=30 time=8.15 ms
64 bytes from 192.168.0.3: icmp_seq=2 ttl=30 time=1.45 ms
64 bytes from 192.168.0.3: icmp_seq=3 ttl=30 time=1.45 ms
64 bytes from 192.168.0.3: icmp_seq=4 ttl=30 time=1.44 ms
64 bytes from 192.168.0.3: icmp_seq=5 ttl=30 time=1.45 ms

--- 192.168.0.3 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 1.449/2.791/8.153/2.681 ms

выключенная машина

Код: Выделить всё

PING 192.168.0.25 (192.168.0.25) 56(84) bytes of data.
From 192.168.0.132 icmp_seq=2 Destination Host Unreachable
From 192.168.0.132 icmp_seq=3 Destination Host Unreachable
From 192.168.0.132 icmp_seq=4 Destination Host Unreachable

--- 192.168.0.25 ping statistics ---
7 packets transmitted, 0 received, +3 errors, 100% packet loss, time 6001ms

proxy-server (DebianEtch)

Код: Выделить всё

PING 192.168.0.250 (192.168.0.250) 56(84) bytes of data.

--- 192.168.0.250 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8000ms

Проверка доступно с той же машины из WindowsXP:
proxy-server (DebianEtch)

Код: Выделить всё

C:\Documents and Settings\Администратор>ping 192.168.0.250

Обмен пакетами с 192.168.0.250 по 32 байт:

Ответ от 192.168.0.250: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.250: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.250: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.250: число байт=32 время<1мс TTL=64

Статистика Ping для 192.168.0.250:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

Меня очень смущает что при ping-е выключенной машины приходит ответ, а при ping-е proxy-server-а никакого ответа не приходит. Это можно было-бы объяснить настройками firewall-а, но тогда бы и при проверках из windows-а ответы не возвращались бы.
Пробовал сменить сетевую карту - картина не изменилась, пингуемые ранее машины пингуются, непингуемые - не пингуются.
Пробовал пинговать пакетами разного размера - в Debian ответа нет, в Windows есть:

Код: Выделить всё

C:\Documents and Settings\Администратор>ping -l 1500 192.168.0.250

Обмен пакетами с 192.168.0.250 по 1500 байт:

Превышен интервал ожидания для запроса.
Ответ от 192.168.0.250: число байт=1500 время<1мс TTL=64
Ответ от 192.168.0.250: число байт=1500 время<1мс TTL=64
Ответ от 192.168.0.250: число байт=1500 время<1мс TTL=64

Статистика Ping для 192.168.0.250:
    Пакетов: отправлено = 4, получено = 3, потеряно = 1 (25% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

C:\Documents and Settings\Администратор>ping -l 2500 192.168.0.250

Обмен пакетами с 192.168.0.250 по 2500 байт:

Ответ от 192.168.0.250: число байт=2500 время<1мс TTL=64
Ответ от 192.168.0.250: число байт=2500 время<1мс TTL=64
Ответ от 192.168.0.250: число байт=2500 время<1мс TTL=64

Статистика Ping для 192.168.0.250:
    Пакетов: отправлено = 3, получено = 3, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

C:\Documents and Settings\Администратор>ping -l 25500 192.168.0.250

Обмен пакетами с 192.168.0.250 по 25500 байт:

Ответ от 192.168.0.250: число байт=25500 время=4мс TTL=64
Ответ от 192.168.0.250: число байт=25500 время=4мс TTL=64
Ответ от 192.168.0.250: число байт=25500 время=4мс TTL=64
Ответ от 192.168.0.250: число байт=25500 время=4мс TTL=64

Статистика Ping для 192.168.0.250:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 4мсек, Максимальное = 4 мсек, Среднее = 4 мсек

C:\Documents and Settings\Администратор>ping -l 32500 192.168.0.250

Обмен пакетами с 192.168.0.250 по 32500 байт:

Ответ от 192.168.0.250: число байт=32500 время=6мс TTL=64
Ответ от 192.168.0.250: число байт=32500 время=5мс TTL=64
Ответ от 192.168.0.250: число байт=32500 время=6мс TTL=64
Ответ от 192.168.0.250: число байт=32500 время=6мс TTL=64

Статистика Ping для 192.168.0.250:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 5мсек, Максимальное = 6 мсек, Среднее = 5 мсек

Дамы и господа, леди и джентельмены, товарищи, друзья! Прошу прощения за банальный вопрос, но - что делать? Принимаются любые идеи.
Я нахожусь в неком замешательстве по сложившейся ситуации и не вижу путей решения.
Спасибо.

Mage-Warrior · Сообщение **Mage-Warrior** » 02.05.2008 19:20

Какое количество данных!!

Приведите, пожалуйста, результат #ip route show из Debian. И вопросик - а у вас "умные" свичи встречаются на пути к proxy-серверу?

IMB · Сообщение **IMB** » 04.05.2008 10:43

Доброго дня!
Данные по роутингу:

Код: Выделить всё

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.250   0.0.0.0         UG    0      0        0 eth0

"Умные" свитчи встречаются, а именно - D-Link DGS-3100-24 (центральный, 192,168,0,1), D-Link DES-3526 (пользовательский этажный, 192,168,0,3). Никаких vlan-ов, запрещающих правил и тому подобного на них не настраивалось.
Привожу результаты ping-ов с указанных свитчей на интересующие меня адреса:
D-Link DGS-3100-24 (центральный, 192,168,0,1)

Код: Выделить всё

DGS3100# ping 192.168.0.250
Pinging 192.168.0.250 with 56 bytes of data:

PING: no reply from 192.168.0.250
PING: timeout
56 bytes from 192.168.0.250: icmp_seq=2. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=3. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=4. time=0 ms

----192.168.0.250 PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 0/0/0

Success.
DGS3100# ping 192.168.0.250
Pinging 192.168.0.250 with 56 bytes of data:

56 bytes from 192.168.0.250: icmp_seq=1. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=2. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=3. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=4. time=0 ms

----192.168.0.250 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0

Success.
DGS3100# ping 192.168.0.250
Pinging 192.168.0.250 with 56 bytes of data:

56 bytes from 192.168.0.250: icmp_seq=1. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=2. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=3. time=0 ms
56 bytes from 192.168.0.250: icmp_seq=4. time=0 ms

----192.168.0.250 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0

Success.
DGS3100# ping 192.168.0.252
Pinging 192.168.0.252 with 56 bytes of data:

PING: no reply from 192.168.0.252
PING: timeout
56 bytes from 192.168.0.252: icmp_seq=2. time=0 ms
56 bytes from 192.168.0.252: icmp_seq=3. time=0 ms
56 bytes from 192.168.0.252: icmp_seq=4. time=0 ms

----192.168.0.252 PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 0/0/0

Success.
DGS3100# ping 192.168.0.252
Pinging 192.168.0.252 with 56 bytes of data:

56 bytes from 192.168.0.252: icmp_seq=1. time=0 ms
56 bytes from 192.168.0.252: icmp_seq=2. time=0 ms
56 bytes from 192.168.0.252: icmp_seq=3. time=0 ms
56 bytes from 192.168.0.252: icmp_seq=4. time=0 ms

----192.168.0.252 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0

D-Link DES-3526 (пользовательский этажный, 192,168,0,3)

Код: Выделить всё

DES-3526:4#ping 192.168.0.250
Command: ping 192.168.0.250

Reply from 192.168.0.250, time<10ms
Reply from 192.168.0.250, time<10ms
Reply from 192.168.0.250, time<10ms
Reply from 192.168.0.250, time<10ms
Reply from 192.168.0.250, time<10ms
Reply from 192.168.0.250, time<10ms

Ping Statistics for 192.168.0.250
Packets: Sent =6, Received =6, Lost =0

DES-3526:4#ping 192.168.0.252
Command: ping 192.168.0.252

Reply from 192.168.0.252, time<10ms
Reply from 192.168.0.252, time<10ms
Reply from 192.168.0.252, time<10ms
Reply from 192.168.0.252, time<10ms
Reply from 192.168.0.252, time<10ms

Ping Statistics for 192.168.0.252
Packets: Sent =5, Received =5, Lost =0

Mage-Warrior · Сообщение **Mage-Warrior** » 04.05.2008 20:40

Оглянув широко поле, осмелюсь посоветовать несколько вариантов по тестированию проблемы.
1. Так как ответ на ping-и не приходит вообще (причем только при загруженном Debian), то это явно похоже на срабатывание фаервола на стороне исследуемой машины. Политика ACCEPT для цепочки INPUT не гарантирует, что пакет обязательно пройдет - есть же еще правила внутри цепочки. Иногда отдельно выделяются правила для ICMP. Я давно не работал с Debian, но можно предположить, что у них появилось что-то вроде динамического определения адресов, которые нужно заблокировать (по какой-то причине - флуд, атаки и пр.). По документации iptables это может быть реализовано с помощью модуля recent и списков в /proc/net/ipt_recent/*. Посему для _реальной_ проверки без iptables очистите все правила! #iptables -X; iptables -F. (и приведите существующие - #iptables -L или #iptables-save)
2. Даже если предыдущий пункт помог и стало яснее (или не помог

), нужно все-таки выделить причину конкретнее, понять ее. Тут нам поможет утилита tcpdump, которая является гибким и довольно удобным средством отлова данных о выходящих и входящих пакетах. Конечно, я посоветую man tcpdump для общего обзора, но и приведу пару примеров для вашего теста:
# tcpdump -vv -i eth0 dst host 192.168.0.250 and ip proto icmp
# tcpdump -vv -i eth0 src host 192.168.0.250 and ip proto icmp
Первый вариант поможет Вам посмотреть, как вылетают со свистом ping-и от локального компа, а второй - наоборот. Параллельно в другой консоли пускается ping. (оба процесса рвутся по ctrl+c в любой момент). Вариантов использования tcpdump ОЧЕНЬ много. Кстати, неплохо бы им попользоваться на proxy для выявления причин.

IMB · Сообщение **IMB** » 05.05.2008 12:42

Спасибо за советы. Получил достаточно интересные результаты. Похоже во всем виноват firewall на proxy.
Вывод iptables-save:

Код: Выделить всё

# Generated by iptables-save v1.3.6 on Mon May  5 11:39:58 2008
*nat
:PREROUTING ACCEPT [8775554:701431229]
:POSTROUTING ACCEPT [6688:1611326]
:OUTPUT ACCEPT [1763089:107335930]
-A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
-A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8080
-A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 20 -j REDIRECT --to-ports 8080
-A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 21 -j REDIRECT --to-ports 8080
-A POSTROUTING -o eth2 -j SNAT --to-source a.b.c.d
COMMIT
# Completed on Mon May  5 11:39:58 2008
# Generated by iptables-save v1.3.6 on Mon May  5 11:39:58 2008
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -s 10.0.0.0/255.0.0.0 -j DROP
-A INPUT -d 10.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 172.16.0.0/255.240.0.0 -j DROP
-A INPUT -d 172.16.0.0/255.240.0.0 -j DROP
-A INPUT -s 192.168.0.0/255.255.0.0 -i eth2 -j DROP
-A INPUT -d 192.168.0.0/255.255.0.0 -i eth2 -j DROP
-A INPUT -s 224.0.0.0/240.0.0.0 -j DROP
-A INPUT -d 224.0.0.0/240.0.0.0 -j DROP
-A INPUT -s 240.0.0.0/248.0.0.0 -j DROP
-A INPUT -d 240.0.0.0/248.0.0.0 -j DROP
-A INPUT -s 127.0.0.1 -j DROP
-A INPUT -d 127.0.0.1 -j DROP
-A INPUT -s 192.168.0.214 -i eth4 -j DROP
-A INPUT -i eth4 -j ACCEPT
-A INPUT -d a.b.c.d -m state --state NEW -j DROP
-A INPUT -d a.b.c.d -m state --state INVALID -j DROP
-A INPUT -d a.b.c.d -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.0.0/255.255.255.0 -i eth4 -j ACCEPT
-A FORWARD -s 192.168.0.132 -i eth4 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -s 10.0.0.0/255.0.0.0 -j DROP
-A OUTPUT -d 10.0.0.0/255.0.0.0 -j DROP
-A OUTPUT -s 172.16.0.0/255.240.0.0 -j DROP
-A OUTPUT -d 172.16.0.0/255.240.0.0 -j DROP
-A OUTPUT -s 224.0.0.0/240.0.0.0 -j DROP
-A OUTPUT -d 224.0.0.0/240.0.0.0 -j DROP
-A OUTPUT -s 240.0.0.0/248.0.0.0 -j DROP
-A OUTPUT -d 240.0.0.0/248.0.0.0 -j DROP
-A OUTPUT -o eth4 -j ACCEPT
-A OUTPUT -o eth2 -j ACCEPT
COMMIT
# Completed on Mon May  5 11:39:58 2008

Используется iptables 1.3.6.0debian1-5.
Но почему это не наблюдается из Windows-машин?

Mage-Warrior · Сообщение **Mage-Warrior** » 05.05.2008 15:25

Почему Вы решили, что виноват firewall на именно на proxy? Очень внимательно рассмотрев приведенные правила, я не увидел проблемы в них? Для прохождения ping-а туда и обратно с интерфейса eth4 не видно. Обязательно попробуйте сбросить правила на клиентской машине приведенными ранее командами. Или по правилам на proxy отбрасывались бы пакеты, если бы они приходили через eth2 (но это, видимо, не возможно - интерфейс смотрит в глобальную сеть). Для выяснения того, где бродят пакеты, пробуйте tcpdump или netwatch (но его собирать нужно и он менее универсальный).

IMB · Сообщение **IMB** » 05.05.2008 18:18

Mage-Warrior писал(а): ↑
05.05.2008 15:25
Почему В решили, что виноват firewall на именно на proxy?

Я использовал tcpdump и с его помощью увидел уход пакетов с клиенткой машины, на proxy пакеты не были зафиксированы. Следующий факт который наводит на firewall - при явном указание машины (iptables --append INPUT --source 192.168.0.x --jump ACCEPT) пакеты начинают ходить. Что интересно - данное правило срабатывает только если стоит первым, если ставлю после запрещающих правил, описывающих различные подсети, пакеты не ходят. Правила на клиентской машине сбрасывались, но это ничего не дало.
Вот такая вот петрушка

Буду разбираться дальше.

Mage-Warrior · Сообщение **Mage-Warrior** » 06.05.2008 12:15

IMB писал(а): ↑
05.05.2008 18:18
Я использовал tcpdump и с его помощью увидел уход пакетов с клиенткой машины, на proxy пакеты не были зафиксированы. Следующий факт который наводит на firewall - при явном указание машины (iptables --append INPUT --source 192.168.0.x --jump ACCEPT) пакеты начинают ходить...

Интересно будет узнать решение. Меня последнее Ваше сообщение наводит все-таки на мысль, что может стоит попробовать #traceroute 192.168.0.250
Чтобы выяснить, какое правило iptables "съедает" входящий пакет можно воспользоваться разными способами.
Первый - самый правильный - перед каждым правилом с -j DROP поставить (можно поочереди, а не сразу все, чтобы не зафлудило лог) идентичное, но с -j LOG --log-prefix IPT_RULE_[номер_правила] . При этом результат можно будет увидеть в dmesg (dmesg|tail -f -n 15). Каждое сообщение при сбросе пакета будет маркироваться указанным префиксом IPT_RULE_[номер_правила].
Второй - выходящий из моих подозрений - поставить первым правилом iptables --append INPUT --source 192.168.0.132 -i eth4 --jump ACCEPT. Проверить результат.

IMB · Сообщение **IMB** » 06.05.2008 16:47

Mage-Warrior писал(а): ↑
06.05.2008 12:15
Второй - выходящий из моих подозрений - поставить первым правилом iptables --append INPUT --source 192.168.0.132 -i eth4 --jump ACCEPT. Проверить результат.

Именно так я сделал для одной из машин, но такой вариант мне не нравиться.
По dmesg|tail -f -n 15 выводится такие данные, не очень мне понятные:

Код: Выделить всё

audit(1209972697.428:72): dev=eth4 prom=256 old_prom=0 auid=4294967295
device eth4 left promiscuous mode
audit(1209972771.542:73): dev=eth4 prom=0 old_prom=256 auid=4294967295
device eth4 entered promiscuous mode
audit(1209972786.656:74): dev=eth4 prom=256 old_prom=0 auid=4294967295
device eth4 left promiscuous mode
audit(1209972821.153:75): dev=eth4 prom=0 old_prom=256 auid=4294967295
device eth4 entered promiscuous mode
audit(1209972835.275:76): dev=eth4 prom=256 old_prom=0 auid=4294967295
device eth4 left promiscuous mode
audit(1209972849.709:77): dev=eth4 prom=0 old_prom=256 auid=4294967295
device eth4 entered promiscuous mode
audit(1209975736.746:78): dev=eth4 prom=256 old_prom=0 auid=4294967295
device eth4 left promiscuous mode
audit(1209975837.924:79): dev=eth4 prom=0 old_prom=256 auid=4294967295

Другой странный факт - если запустить ping и он не идет сразу, то минут через 10-15 начинает ходить:

Код: Выделить всё

64 bytes from 192.168.0.250: icmp_seq=548 ttl=64 time=0.148 ms
64 bytes from 192.168.0.250: icmp_seq=549 ttl=64 time=0.210 ms
64 bytes from 192.168.0.250: icmp_seq=550 ttl=64 time=0.134 ms
64 bytes from 192.168.0.250: icmp_seq=551 ttl=64 time=0.188 ms
64 bytes from 192.168.0.250: icmp_seq=552 ttl=64 time=0.114 ms
64 bytes from 192.168.0.250: icmp_seq=553 ttl=64 time=0.161 ms
64 bytes from 192.168.0.250: icmp_seq=554 ttl=64 time=0.211 ms
64 bytes from 192.168.0.250: icmp_seq=555 ttl=64 time=0.141 ms
64 bytes from 192.168.0.250: icmp_seq=556 ttl=64 time=0.192 ms
64 bytes from 192.168.0.250: icmp_seq=557 ttl=64 time=0.116 ms
64 bytes from 192.168.0.250: icmp_seq=558 ttl=64 time=0.159 ms
64 bytes from 192.168.0.250: icmp_seq=559 ttl=64 time=0.211 ms
64 bytes from 192.168.0.250: icmp_seq=560 ttl=64 time=0.137 ms

--- 192.168.0.250 ping statistics ---
560 packets transmitted, 346 received, 38% packet loss, time 559104ms
rtt min/avg/max/mdev = 0.085/0.162/3.170/0.166 ms

Ну и соответственно при ходящим пингах traceroute:

Код: Выделить всё

 traceroute 192.168.0.250
traceroute to 192.168.0.250 (192.168.0.250), 30 hops max, 40 byte packets
 1  192.168.0.250 (192.168.0.250)  0.183 ms  0.128 ms  0.139 ms

Буду разбираться дальше.

Mage-Warrior · Сообщение **Mage-Warrior** » 06.05.2008 18:21

Во-первых, обратите внимание, что в iptables --append INPUT --source 192.168.0.132 -i eth4 --jump ACCEPT выделен eth4. Это важно. Важно знать, что пакеты приходят с нужного интерфейса. Мало ли какие петли бывают

Странно, что ping-и начинают проходить через 15 минут. Это даже подозрительно. Попробуйте при пропадании пингов команду #arp -a (#arping -I 192.168.0.250) и её же во время их работы. Сравните MAC-адреса, соответствующие 192.168.0.250. Это с подозрением, что у Вас время от времени появляется еще кто-то с таким же ip-адресом. Тогда, те кто был в сети до появления "двойника" успели узнать правильный MAC-адрес и поддерживали его использование за счёт постоянного обмена данными (давно не освежал это в памяти, потому могу быть не точен!). Если Ваша система загружалась при действующем "двойнике", то могла получить MAC двойника. И только после его "отмирания" или выхода из сети рассматриваемый комп мог получить правильный MAC. У меня возникает ощущение, что дело тут не во времени, а в каких-то действиях на сервере или в сети.
Вывод dmesg был бы полезен, если бы Вы сделали правила с действиями LOG, как было указано ниже, и в то же время сервер бы безответно пинговался с машины 192.168.0.132. Это было сделано? Если было и результат именно таков, как Вы привели, то пакеты не приходят вовсе. Тут можно и подумать о подмене адресов.
P.S. Ну, и проблемка. Иногда очень хочется взять в дело в свои руки.

IMB · Сообщение **IMB** » 08.05.2008 13:04

Спасибо за совет!
Похоже проблема действительно в подмене MAC-ов.
arp -a с локальной машины:

Код: Выделить всё

? (192.168.0.250) at 4C:00:10:A1:95:AD [ether] on eth0

вывод ifconfig с proxy-сервера:

Код: Выделить всё

eth2      Link encap:Ethernet  HWaddr 4C:00:10:A1:95:AD
          inet addr:a.b.c.d  Bcast:e.f.g.h  Mask:255.255.255.240

eth4    Link encap:Ethernet  HWaddr 00:0E:0C:B7:54:FF
          inet addr:192.168.0.250  Bcast:192.168.0.255  Mask:255.255.255.0

Схема подключения машин следующая - на центральный свитч (D-Link DGS-3100-24) заходит uplink от провайдера, к нему же подключены все сервера.
Будем думать как решить проблему.

Mage-Warrior · Сообщение **Mage-Warrior** » 08.05.2008 18:20

Вот так да! Должен сказать, что ожидал подмены IP, а не такого странного поведения. Выходит, что пакет падает вообще не на тот интерфейс, а пинги начинают ходить после обновления arp-таблицы. Можно произвести эксперимент, вручную удалив запись (arp -d 192.168.0.250) и тут же попробовав пинг. Только все же непонятно, почему на arp-запрос отвечает другой интерфейс...

Кстати, никак не пойму, зачем это правило:

Код: Выделить всё

-A FORWARD -d 192.168.0.0/255.255.255.0 -i eth4 -j ACCEPT

Одна идея - попробуйте добавить

Код: Выделить всё

-A OUTPUT -d 192.168.0.0/255.255.0.0 -o eth2 -j DROP

перед

Код: Выделить всё

-A OUTPUT -o eth2 -j ACCEPT

Сообщение **KiWi** » 08.05.2008 19:36

IMB писал(а): ↑
08.05.2008 13:04
Схема подключения машин следующая - на центральный свитч (D-Link DGS-3100-24) заходит uplink от провайдера, к нему же подключены все сервера.

Из вышенаписанного я правильно поминаю, что eth2 & eth4 воткнуты в этот самый dlink?

IMB · Сообщение **IMB** » 08.05.2008 20:03

KiWi писал(а): ↑
08.05.2008 19:36
Из вышенаписанного я правильно поминаю, что eth2 & eth4 воткнуты в этот самый dlink?

Да, именно так и обстоит дело.

Сообщение **KiWi** » 08.05.2008 20:35

IMB писал(а): ↑
08.05.2008 20:03
KiWi писал(а): ↑
08.05.2008 19:36
Из вышенаписанного я правильно поминаю, что eth2 & eth4 воткнуты в этот самый dlink?

Да, именно так и обстоит дело.

Это, эм, не особо хорошо.
Если втыкать, то только одну сетевушку и вешать алиасы. Либо 2 сетевушки, но создавать транк.
Хотя... там же наверно и разные подсети от провайдера/клиентов/серверов? Тогда, если нормально, то либо менять свитч на поддерживающий port-based vlan'ы(этот, судя по докам, такого не умеет -- только tagged vlan'ы), либо вообще разносить на 2 свитча...

P.S.: а на портах какие маки прописываются?

IMB · Сообщение **IMB** » 08.05.2008 20:55

KiWi писал(а): ↑
08.05.2008 20:35
P.S.: а на портах какие маки прописываются?

Специально на свитче ничего, кроме адреса, ничего не настраивалось. Если смотреть таблицу MAC-адресов, но эти интерфейсы находятся на разных портах, что соответствует действительности.
P.S. Если виноват свитч, то почему в Windows такого не наблюдается?
P.S. Касательно типов vlan-ов поддерживаемых свитчом. Насколько я понимаю поддерживаются port-based и tagged.

Код: Выделить всё

Each VLAN name can be up to 32 characters. If the VLAN is not given a tag, it will be a port-based VLAN.

Сообщение **KiWi** » 08.05.2008 21:09

IMB писал(а): ↑
08.05.2008 20:55
P.S. Касательно типов vlan-ов поддерживаемых свитчом. Насколько я понимаю поддерживаются port-based и tagged.

Вот лучше и разведите vlan'ами uplink + proxy в отдельный vlan(мб, что-то ещё -- не знаю как и чо у вас настроено).

IMB · Сообщение **IMB** » 10.05.2008 13:26

Доброго дня!
Хочу поблагорить за оказанную помощь Mage-Warrior и подключивщегося KiWi. Данное сообщение я пишу из Debian-а и надеюсь что проблема решена, но в причинах очень хочется разобраться.
На данный момент, проблему я решил добавление статической записи в arp-таблицу:

Код: Выделить всё

auto eth0
iface eth0 inet static
        address 192.168.0.132
        netmask 255.255.255.0
        gateway 192.168.0.250
        post-up /usr/sbin/arp -s 192.168.0.250 00:0E:0C:B7:54:FF
        pre-down /usr/sbin/arp -d 192.168.0.250

Привожу таблицы роутинга из Debian-а и Windows-а:
Debian

Код: Выделить всё

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.250   0.0.0.0         UG    0      0        0 eth0

Windows

Код: Выделить всё

===========================================================================
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0f ea ce b1 28 ...... Realtek RTL8169/8110 Family Gigabit Ethernet NIC
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0    192.168.0.250   192.168.0.132       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0    255.255.255.0    192.168.0.132   192.168.0.132       20
    192.168.0.132  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.0.255  255.255.255.255    192.168.0.132   192.168.0.132       20
        224.0.0.0        240.0.0.0    192.168.0.132   192.168.0.132       20
  255.255.255.255  255.255.255.255    192.168.0.132   192.168.0.132       1
Основной шлюз:       192.168.0.250
===========================================================================
Постоянные маршруты:

svk · Сообщение **svk** » 11.05.2008 13:42

Это не решение проблемы, а костыль.
я бы на длинке запретил прохождение пакетов между портами, в которые вставлены эти две сетевухи:
conf traffic_ первый_порт for все_порты_кроме_второго_порта
conf traffic_ второй_порт for все_порты_кроме_первого_порта

например если всего в свиче 24 порта и сервер подключен в 5й и 9й, то это будет так:
conf traffic_ 5 for 1-8,10-24

ну и аналогично для другого:
conf traffic_ 9 for 1-4,6-24

IMB · Сообщение **IMB** » 11.05.2008 14:25

svk писал(а): ↑
11.05.2008 13:42
Это не решение проблемы, а костыль.
я бы на длинке запретил прохождение пакетов между портами, в которые вставлены эти две сетевухи:

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

Сообщение **KiWi** » 11.05.2008 14:32

svk писал(а): ↑
11.05.2008 13:42
Это не решение проблемы, а костыль.

А при такой идиотской организации сети -- нормальных решений не будет. (:

unixforum.org

realtek 8169 (в Debian нет связи с некоторыми узлами)

realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169

Re: realtek 8169