Вторая сетевая не пингуется по подключённому к ней шнурку

[ais77]

Собственно, сабж - я в полном недоумении о причинах происходящего,
2 дня уговоров и так, и эдак ни к чему не привели... 

Ubuntu Server 9.10, установлен с нуля. В системе 2 интерфейса:
eth1 (192.168.1.2) 100МБ ----------> смотрит в АДСЛ роутер (везде IP-шники статические, никаких DHCP)
eth0 (192.168.1.3) 1ГБ ----------> должен смотреть в локальную сеть (из одного девайса - Playstation 3)
Оба интерфейса поднимаются/опускаются без ошибок.

Подключаю шнуроком ХР-ноут к гигабитной карточке eth0, выставляю на ноуте, скажем, 192.168.1.16, сеть устанавливается, пытаюсь пинговать eth0 - таймауты 
Шнурки проверены: при подключении ноута ими же к роутеру - все адреса сети пингуются без проблем.

Причём (для меня это оказалось новостью) - кабели обоих типов: и обычный патчкорд, и нуль-хаб (то, что раньше называлось twisted pair) работают оба.    Видимо, современные сетевухи научились определять тип кабеля и сами внутри себя соответственно коммутируют линии.
21-й век на дворе, а я и не заметил...

Но к главному вопросу - где рыть? Как может не пинговаться интерфейс с линии, к нему подключённой?


~$cat /etc/network/interfaces

(Нажмите, чтобы показать/скрыть)

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth1
iface eth1 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1
        dns-search home

# Gigabit network interface
auto eth0
iface eth0 inet static
        address 192.168.1.3
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255

~$ ifconfig -a

(Нажмите, чтобы показать/скрыть)

eth0      Link encap:Ethernet  HWaddr 00:1e:58:aa:58:f8
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:58ff:feaa:58f8/64 Диапазон:Ссылка
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:190 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          коллизии:0 txqueuelen:1000
          RX bytes:24596 (24.5 KB)  TX bytes:3689 (3.6 KB)
          Прервано:22

eth1      Link encap:Ethernet  HWaddr 00:07:e9:da:47:c8
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::207:e9ff:feda:47c8/64 Диапазон:Ссылка
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:279215 errors:0 dropped:0 overruns:0 frame:0
          TX packets:426899 errors:0 dropped:0 overruns:0 carrier:0
          коллизии:0 txqueuelen:1000
          RX bytes:22174343 (22.1 MB)  TX bytes:538483293 (538.4 MB)

lo        Link encap:Локальная петля (Loopback)
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Диапазон:Узел
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5017 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5017 errors:0 dropped:0 overruns:0 carrier:0
          коллизии:0 txqueuelen:0
          RX bytes:310716 (310.7 KB)  TX bytes:310716 (310.7 KB)

на всякий случай (хотя, это уже следующий этап) - ещё
~$ route -v

(Нажмите, чтобы показать/скрыть)

Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
localnet        *               255.255.255.0   U     0      0        0 eth1
localnet        *               255.255.255.0   U     0      0        0 eth0
default         nc29.home       0.0.0.0         UG    100    0        0 e

Вывел с помощью tcpdump реакцию eth0 на пинг с ноута (192.168.1.16). Может, это что-то объяснит людям знающим?

(Нажмите, чтобы показать/скрыть)

ms.local - это сервер (ms = Media Server)
nc29 - это АДСЛ-роутер (NetComm)

~$ sudo tcpdump -i eth0 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:20:57.260882 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has ms.local tell 192.168.1.16, length 46
16:21:01.428547 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 70)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 3.1.168.192.in-addr.arpa. (42)
16:21:01.428916 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 86)
    ms.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 3.1.168.192.in-addr.arpa. (Cache flush) PTR[|domain]
16:21:02.561359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has ms.local tell 192.168.1.16, length 46
16:21:05.703868 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 71)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 16.1.168.192.in-addr.arpa. (43)
16:21:06.705689 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 71)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 16.1.168.192.in-addr.arpa. (43)
16:21:08.062947 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has ms.local tell 192.168.1.16, length 46
16:21:08.708446 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 71)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 16.1.168.192.in-addr.arpa. (43)
16:21:13.565523 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has ms.local tell 192.168.1.16, length 46
16:21:14.746969 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 70)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
16:21:15.748752 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 70)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
16:21:17.749943 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 70)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
16:21:37.448490 IP (tos 0x0, ttl 128, id 28773, offset 0, flags [none], proto UDP (17), length 241)
    192.168.1.16.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
16:21:41.709853 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 72)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.168.192.in-addr.arpa. (44)
16:21:42.711666 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 72)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.168.192.in-addr.arpa. (44)
16:21:44.713909 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 72)
    ms.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.168.192.in-addr.arpa. (44)
16:21:56.363710 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has nc29.home tell 192.168.1.16, length 46
16:22:00.363028 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has nc29.home tell 192.168.1.16, length 46
^C
22 packets captured
22 packets received by filter
0 packets dropped by kernel

Помогите советом - где могут быть грабли?

[Tokh]

Обе сетевые карты сервера в одной подсети. По таблице маршрутов eth1 на сервере стоит раньше eth0. Всё предназначенное для 192.168.1.0/24 должно уходить только в eth1 согласно таблице маршрутов. Всё для 192.168.1.16 шлётся через eth1 в ДСЛ шлюз где и пропадает. Интереснее посмотерть на вывод "route -n -v", без непонятных доменных имён, сразу с IP адресами.

Сделайте подсеть позади eth0, например, 10.22.33.0/24 или 192.168.2.0/24 . Это будет проще и правильно.

Комментарий: рing использует ICMP протокол, а в выводе tcpdump этого нет, там только UDP.
Можно использовать

Код: [Выделить]

tcpdump -nn -i eth0 | grep ICMP | grep 192.168.1.3 для отлова пингов.

P.S. Да, современные коммутаторы и сетевые карты умеют работать как с "перевёрнутыми" кросоверами-кабелями и так и с "прямыми".

[El Scorpio]

eth1 (192.168.1.2) 100МБ ----------> смотрит в АДСЛ роутер (везде IP-шники статические, никаких DHCP)
eth0 (192.168.1.3) 1ГБ ----------> должен смотреть в локальную сеть (из одного девайса - Playstation 3)

Две сетевые карты в одной подсети нормально работать не будут.
Можно назначить "локальной сети"  другой диапазон, например 192.168.2.x
А что за марка ADSL-модема?
Если он многопортовый, проще будет воткнуть оба устройства в него, поднять NAT и не заморачиваться настройкой маршрутизации на компьютере.

[ais77]

Сделайте подсеть позади eth0, например, 10.22.33.0/24 или 192.168.2.0/24 . Это будет проще и правильно.

Brilliant! Вы абсолютно правы, мой респект и уважение! Создал вторую подсеть - пинги забегали как родные.  

Сейчас роутинг выглядит как

(Нажмите, чтобы показать/скрыть)

$ route -n -v
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
239.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 eth0
239.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 eth1

По моему разумению все пакеты, адресуемые вовне (DNS и интернет-запросы) должны бы отправляться по дефолтному роуту на модем через eth1, ведь так?
Но с eth0 пинг вовне не проходит, DNS не ресолвится... :- I  P-форвардинг в sysctl.conf включён. Чего я ещё не понимаю?

Ставить ipmasq и dnsmasq (как советуют в теме о шлюзе интернета) мне, почему-то, кажется костыльным решением для подсети из одной машины, хочется соблюсти чистоту жанра, но главное - понять... Благодарю Вас заранее.
Пользователь решил продолжить мысль 23 Ноября 2009, 12:14:11:

Если он многопортовый, проще будет воткнуть оба устройства в него, поднять NAT и не заморачиваться настройкой маршрутизации на компьютере.

Так и работало. Потребность в отдельном гигабитном интерфейсе для Playstation вызвана тем, что для передачи с сервера HD-видео (1080р) 100Мб-сети часто не хватает - картинка замирает + на этом же канале ещё Transmission работает, ssh, ftp... В общем, медиасерверу - медиасерверный коннект  

[Tokh]

Ставить ipmasq и dnsmasq (как советуют в теме о шлюзе интернета) мне, почему-то, кажется костыльным решением для подсети из одной машины

Да, нет нужды ставить ipmasq и dnsmasq. Эти пакеты маскируют внутренние серые адреса от внешнего мира. Это уже делается на модеме-шлюзе в интернет и того достаточно. Тут же - только маршрутизация. В своей локалке можно городить сколь угодно много шлюзов и не делать маскарадинг, не делать трансляцию адресов, независимо от серости или белости адресов.

Можно проверить, что

Код: [Выделить]

cat /proc/sys/net/ipv4/ip_forwardдействительно даёт единицу, т.е. срабатывает настройка в sysctl.conf

На каждом комп-е позади eth0 нужно прописать шлюзом по умолчанию 192.168.2.1 Т.к. именно 192.168.2.1 знает где находится модем и остальной мир, на нём прописаны маршруты к остальному миру.

У всех компов для начала прописать адреса DNS даваемые провайдером, потом можно будет переписать на 192.168.1.1, когда заработает. Обычно дают пару адресов, скорее всего адреса можно посмотреть в настройках модема и, конечно, на сайте провайдера.

Посмотреть на Ubuntu Server

Код: [Выделить]

sudo iptables -S Должен быть разрешён весь трафик через цепь FORWARD.

При этом, параллельно можно tcpdump'ом или графической Wireshark посмотреть на всех компьютерах по очереди как идут пакеты с пингами, т.е. пакеты в описании которых стоит ICMP. Иногда может дать подсказку, иногда нет.

Но с eth0 пинг вовне не проходит, DNS не ресолвится

Что именно пингуется, доменное имя или IP адрес?

Когда с DNS проблемы, можно на сервере, или ещё где, пингануть адрес www.ubuntu.com, запомнить ip адрес и по этому ip адресу с "внутренней" машины зайти на сайт через Firefox. Или пингануть сам IP адрес. Если заработает, значит - да, ДНС шалит. Иначе - есть что ещё.

[ais77]

действительно даёт единицу, т.е. срабатывает настройка в sysctl.conf
...
Посмотреть на Ubuntu Server

Код: [Выделить]

sudo iptables -S Должен быть разрешён весь трафик через цепь FORWARD.
...
Что именно пингуется, доменное имя или IP адрес?

1) точно так
2) таблица чистая, у меня (пока был usb-модем) запускался скрипт, настраивавший вайерволл на iptables, сейчас я за роутером и надобности в нём, как бы, нет

Код: [Выделить]

# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT3) в том и дело - что ни по адресу, ни (естественно) по имени..
Что-то с роутингом, как я понимаю... Но что?

[Tokh]

1) Тогда из локалки пингуется ли eth1 с адресом 192.168.1.2, наружний адрес сервера?
2) Если пингуется наружний интерфейс шлюза, то вместо модема поставить компьютер с модемным адресом 192.168.1.1 и пинговать из локалки "192.168.1.1".

Если при подстановке компьютера этот 192.168.1.1 начнёт пинговаться, то:

(Нажмите, чтобы показать/скрыть)

Возникает вопрос как модем поступит с адресами 192.168.2.0/24. Я никогда не пробовал именно модем в этой топологии сети. Если задуматься, то не очевидно, что модем не выбросит адреса не совпадающие со своей внутренней сетью 192.168.1.0/24. Если дело в этом, то можно и нужно ставить пакеты для маскарадинга - модем такой...

Или попытаться в модеме установить "внутреннее" адресное пространство 192.168.0.1/22 (это от *.0.0 до *.3.0) или вообще 192.168.0.1/16. При этом на остальных машинах оставить прежние маски подсетей.

Но это всё только если пингуется 192.168.1.1 на компе подставном вместо модема и не пингуется когда там модем. Если из локалки никак не пингуется eth1 или 192.168.1.1 позади, то дело в шлюзе.

В локалке нет опечаток в настройках на компах?

[Гарри Кашпировский]

Вы не забывайте еще о том, что и модем ADSL-роутер должен знать о сети 192.168.2.0/24

[Tokh]

Точно!

Модем в сети 192.168.1.0/24 ничего не знает про сеть 192.168.2.0/24 Вот через сервер приходят модему пакеты от 192.168.2.16 . Модем или сам отвечает или натит-маскарадит эти пакеты, формирует какие-то ответные пакеты, но, а куда модему отправлять ответы для адреса 192.168.2.16, позади какого интерфейса искать адрес 192.168.2.16? В таблице маршрутов модема нет 192.168.2.0/24, но зато есть шлюз по умолчанию, шлюз куда слать всё что не подошло под остальные правила, и это шлюз провайдера, ну модем и шлёт эти ответы в другую сторону, провайдеру.

Модем-то тоже должен иметь маршрут куда отправлять пакеты адресованные любому из 192.168.2.0/24. Для обычного Линукс компьютера на месте модема маршрут задавался бы так
route add -net 192.168.2.0/24 gw 192.168.1.2
У модема может быть есть веб интерфейс для описания маршрутов, и там надо указать, что для сети 192.168.2.0/24 шлюз имеет адрес 192.168.1.2

Или иначе - правда ipmasq и dnsmasq... Вся локалка будет для модема выступать как один единственный 192.168.2.1 и вопрос маршрутов на модеме не возникнет.

[Гарри Кашпировский]

> Да, нет нужды ставить ipmasq и dnsmasq
> Или иначе - правда ipmasq и dnsmasq
Somewhere there out there, Вы уж определитесь ставить или нет
Честно говоря я в ipmasq не вижу смысла, фактически, те же функции выполняет iptables (цепочка NAT)
> На каждом комп-е позади eth0 нужно прописать шлюзом по умолчанию 192.168.2.1 Т.к. именно 192.168.2.1 знает где находится модем и остальной мир, на нём прописаны маршруты к остальному миру.
А вот этого не нужно делать. См свой пример с модемом.

[ais77]

Вы не забывайте еще о том, что и модем ADSL-роутер должен знать о сети 192.168.2.0/24

Somewhere there out there, Гарри Кашпировский, Вы абсолютно правы.
Настроил правило на АДСЛ-роутере (есть там такое меню) - отправлять все пакеты, предназначенные для подсети 192.168.2.0/24, на интерфейс eth1 (192.168.1.2) - и всё заработало.  
Модем, действительно, не понимал, куда ответ-то отправлять на запрос, пришедший из такой сети - для него-то этой сети не существовало...
Вот и слал их, бедный, на роутинг по-умолчанию - в инет  
Спасибо Вам ОГРОМНОЕ!

PS:

А вот этого не нужно делать. См свой пример с модемом.

Именно так я и сделал: gateway 192.168.2.1. Но DNS, при этом - 192.168.1.1. Работает!)))

[AnrDaemon]

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

[ais77]

Мне нужен гигабитный коннект между сервером PS3, как я выше писал - вот почему появилась вторая карточка. А гигабитный свитч - это дополнительные расходы...

В сторону бриджа между карточками я уже смотрел - и даже поднимать его пытался, но, почему-то, в этой конфигурации пропал доступ с сервера в инет, что неприемлемо однозначно - отложил эту идею... Сейчас есть рабочая конфигурация - можно забэкапить её и поиграться.

Но, если я правильно понимаю - бридж смешивает пакеты с обоих интерфейсов в одну кучу, а они по-разному нагружены: eth0 - это выделенный гигабит для HD-видеотрафика, тогда как eth1 - 100Мь и относительно слабо нагруженный, только инетом и локальным ssh, зачем и на нём ещё гигабитные пакеты, не будут они мешать?

[AnrDaemon]

Не могу точно сказать, но думаю, что не должно ничего мешаться.
Мост - штука логическая, объединяет несколько физических интерфейсов одним логическим адресом.
Хотя... вообще, стОит на бумажке изобразить сеть и подумать с карандашом в руке, как и что должно бегать.

[El Scorpio]

Мне нужен гигабитный коннект между сервером PS3, как я выше писал - вот почему появилась вторая карточка. А гигабитный свитч - это дополнительные расходы...

Уважаемый, "вторая сетевая карточка" из воздуха появилась? Гигабитный свитч стоил бы ненамного дороже.
Опять же, личное время, затрачиваемое на настройку маршрутизации, тоже в деньги перевести можно