The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Linux и 2й уровень"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Linux и 2й уровень"  
Сообщение от Lt_Flash email(ok) on 25-Июн-07, 17:41 
Добрый день. Такая ситуация, никак не пойму, почему происходит такая ситуация.

Имеется две линукс-машины. Настроены на одну сеть, все нормально, друг друга видят. Предположим, что машины имеют адреса 172.17.17.30 и 172.17.194.3

Далее делаем следующее:
На одной из машин делаем статический арп с заведомо НЕВЕРНОЙ записью. Вот как было:
linux_2 (172.17.194.3)        ether   00:15:E9:40:0E:4C   C                     eth0

Вот что делаем:

arp -s -i eth0 172.17.194.3 44:18:F3:98:DB:AD

linux_2 (172.17.194.3)        ether   44:18:F3:98:DB:AD   CM                    eth0

Все хорошо, в арп-таблице у нас теперь неверная запись. Проверяем пинг этой машины:

PING 172.17.194.3 (172.17.194.3) 56(84) bytes of data.
64 bytes from 172.17.194.3: icmp_seq=1 ttl=64 time=1.93 ms
64 bytes from 172.17.194.3: icmp_seq=2 ttl=64 time=0.566 ms

Пинги никуда не пропали. Лезу в тцпдамп, вот что вижу:

21:21:09.989628 IP 172.17.17.30 > 172.17.194.3: ICMP echo request, id 9264, seq 2, length 64
        0x0000:  4418 f398 dbad 001a 9235 fafa 0800 4500  D........5....E.
        0x0010:  0054 0000 4000 4001 0f65 ac11 111e ac11  .T..@.@..e......
        0x0020:  c203 0800 1c71 2430 0002 85f9 7f46 b819  .....q$0.....F..
        0x0030:  0f00 0809 0a0b 0c0d 0e0f 1011 1213 1415  ................
        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425  ...........!"#$%
        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435  &'()*+,-./012345
21:21:09.990192 IP 172.17.194.3 > 172.17.17.30: ICMP echo reply, id 9264, seq 2, length 64
        0x0000:  001a 9235 fafa 0015 e940 0e4c 0800 4500  ...5.....@.L..E.
        0x0010:  0054 0004 4000 4001 0f61 ac11 c203 ac11  .T..@.@..a......
        0x0020:  111e 0000 2471 2430 0002 85f9 7f46 b819  ....$q$0.....F..
        0x0030:  0f00 0809 0a0b 0c0d 0e0f 1011 1213 1415  ................
        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425  ...........!"#$%
        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435  &'()*+,-./012345

Как видно из тцпдампа, пакеты уходят на НЕВЕРНЫЙ мак (0x0000:  4418 f398 dbad) соответственно с локальной таблицей арпов (что верно), удаленная машина переспрашивает арпом "у кого есть ИП 172.17.17.30" (если еще не закешировала запись), получает его мак и отвечает на него уже с верным сурсом и дестом.

Так вот вопрос - с чего вдруг удаленная машина принимает пакет с НЕ АДРЕСОВАННЫМ ей маком??? Отвечает-то нормально, т.е. берет смотрит арп-кеш, если там нет удаленного ИП - запрашивает и уже туда кидает пакет. Весь вопрос в том, почему пакет ПРИНЯТ и обработан, если НЕ адресован ЭТОЙ машине? Получается, линукс работает на чистом 3м уровне и на второй уровень ему вообще по барабану чтоли? Главное - чтобы ИП-адрес совпал и все? А как бы переключить его все же в режим работы 2го левела - когда машина принимает пакет, смотрит на дест мак и если не имеет такого мака у себя на интерфейсах - дропает пакет ДО просмотра содержимого заголовка 3го уровня? Заранее всем спасибо.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Linux и 2й уровень"  
Сообщение от vic (??) on 25-Июн-07, 18:05 
что на удаленной с promiscuous режимом (при запуске tcpdump он включается автоматом)?

ваще сетевая карта (железка) в обычном режиме игнорит все кроме щироковещательных и своих eth-фреймов, бродкасты может принимать (кстати статически неверный адрес бродкастом не является?)

при promiscuous принимаются все пакеты и в этом случае линух может захавать и с кривым маком, т.к. IP совпадает (так ли точно не наю). Может есть настройка в /proc/... включающаая более строгий режим.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Linux и 2й уровень"  
Сообщение от Lt_Flash email(ok) on 25-Июн-07, 18:11 
>что на удаленной с promiscuous режимом (при запуске tcpdump он включается автоматом)?
>
Выключен он, я на ней тцпдампом не слушаю, даже консолью не захожу, все приведенные тцпдампы - с машины-отправителя. Вот ифконфиг ее же ифейса:

eth0      Link encap:Ethernet  HWaddr 00:1A:92:35:FA:FA
          inet addr:172.17.17.30  Bcast:172.17.255.255  Mask:255.255.0.0
          inet6 addr: fe80::21a:92ff:fe35:fafa/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6930787 errors:0 dropped:0 overruns:0 frame:0
          TX packets:452321 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1013999442 (967.0 MiB)  TX bytes:164980327 (157.3 MiB)
          Interrupt:17 Base address:0xe000


>
>ваще сетевая карта (железка) в обычном режиме игнорит все кроме щироковещательных и
>своих eth-фреймов, бродкасты может принимать (кстати статически неверный адрес бродкастом не
>является?)
Нет, не является...
>
>при promiscuous принимаются все пакеты и в этом случае линух может захавать
>и с кривым маком, т.к. IP совпадает (так ли точно не
>наю). Может есть настройка в /proc/... включающаая более строгий режим.
Ну вот где бы эту настройку найти и понять как она работает...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Linux и 2й уровень"  
Сообщение от vic (??) on 26-Июн-07, 14:06 
>>что на удаленной с promiscuous режимом (при запуске tcpdump он включается автоматом)?
>Выключен он,
Ок

>>ваще сетевая карта (железка) в обычном режиме игнорит все кроме щироковещательных и
>>своих eth-фреймов, бродкасты может принимать (кстати статически неверный адрес бродкастом не
>>является?)
>Нет, не является...
я ведь почему спросил? ваш неверный адрес 44:18:F3:98:DB:AD (скопировал из первого поста)
смотрим первые два левых бита числа 44, оно же 01000100b, первые (слева) два бита не должны быть = 1, а у вас второй равен 1, (первый отвечает за шароковещательность, второй указывает на locally administered address), в таких случаях фрейм будет принят, но обработка мак-адреса идет по другой цепочке. Попробуйте 00:18:F3:98:DB:AD, если ситуция будет та же, надо искать в /proc... и читать мануалы.

описание мак адресов http://en.wikipedia.org/wiki/MAC_address
но лучше скурить все rfc по теме.

p.s. иногда встречаются системы и устройства нарушающие и rfc и стандарты ((

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Linux и 2й уровень"  
Сообщение от Lt_Flash (ok) on 26-Июн-07, 14:14 
Спасибо, попробовал просто поменять в правильном адресе сетевухи последний бит - та же картина.

Начал проводить исследование дальше. Смотрю теперь тцпдампом на принимающей машине, что происходит. Режим промискус отключил опцией -p тцпдампа. Так вот, что интересно. У меня между этими линуксами стоят свитчи Allied Telesyn разные, например 8024.

Так вот, смотрю на машине-отправителе, где чуток поправлен мак-адрес второй машины. Пакет уходит с неправильным маком (поменял в маке последний байт на +1, например было 00-15-e9-40-0e-4c, я вбил 4d). А на целевой машине пакет приходит уже со всеми верными реквизитами! И вторая машина отвечает уже на верный мак! Такое впечатление, что свитч сам просматривает свои таблицы мак-адресов на предмет совпадений ИП-адресов и проставляет верные МАКи. Сегодня-завтра буду пробовать тупо соединить патчем два линукса и проверять без свитча между ними.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Linux и 2й уровень"  
Сообщение от vic (??) on 26-Июн-07, 19:34 
>Спасибо, попробовал просто поменять в правильном адресе сетевухи последний бит - та
>же картина.
>
>Начал проводить исследование дальше. Смотрю теперь тцпдампом на принимающей машине, что происходит.
>Режим промискус отключил опцией -p тцпдампа. Так вот, что интересно. У
>меня между этими линуксами стоят свитчи Allied Telesyn разные, например 8024.

Ага!!! есть посредники =)))

[skip]
>Такое впечатление, что свитч сам просматривает свои таблицы
>мак-адресов на предмет совпадений ИП-адресов и проставляет верные МАКи.

повторю свое зы:
p.s. иногда встречаются системы и устройства нарушающие и rfc и стандарты :))

>Сегодня-завтра буду пробовать тупо соединить патчем два линукса и проверять без свитча между ними.
Будет интересно узнать как линух поведет себя. Свичи забракуем - че та они шибко умные =)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Linux и 2й уровень"  
Сообщение от Lt_Flash (ok) on 26-Июн-07, 23:02 
Подключал напрямую - все чисто, пинги пропадают, как только делаешь "неправильный" мак на машине с исходящими пакетами. Пробовал в тупой тренднет 5-портовый свитч втыкать - пакеты не пропадают, а приходят с верными маками. Я фигею, дорогая редакция...Ну не должны же свитчи 2го уровня себя так вести! Они ж ничего не знают о 3м уровне, держат только таблицу маков...

Хотя приходит в голову решение...Свитч когда принимает неизвестный ему мак тупо бродкастит пакет во все порты. Далее линукс принимает этот пакет (вот тут уже непонятки начинаются, ибо нафига он его принимает???), делает arp who-has и отвечает уже на правильный полученный мак. Но тцпдамп вроде бы показывает что пакет УЖЕ приходит с правильным маком...А получается виноват только свитч...Т.е. судя по тцпдампу:

1. Приходит пакет с уже верными мак-ип
2. Сервер куда пришел пакет делает arp who-has
3. Сервер отвечает на верный ИП-МАК.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Linux и 2й уровень"  
Сообщение от vic (??) on 27-Июн-07, 12:35 
>Они ж ничего не знают о 3м уровне, держат только таблицу маков...
как бы..
>
>Хотя приходит в голову решение...Свитч когда принимает неизвестный ему мак тупо бродкастит
>пакет во все порты. Далее линукс принимает этот пакет (вот тут
>уже непонятки начинаются, ибо нафига он его принимает???), делает arp who-has
>и отвечает уже на правильный полученный мак. Но тцпдамп вроде бы
>показывает что пакет УЖЕ приходит с правильным маком...А получается виноват только
>свитч...Т.е. судя по тцпдампу:
>
>1. Приходит пакет с уже верными мак-ип
если так, то свич похоже анализирует IP адрес и правит MAC, надо на них спеку читать.
Разные свичи - разное поведение. Возможно работает на так сказать 2.5 уровне..
Наличие/отсутствие бродкаста у свича при приходе пакета с неверным МАК можно проверить третьей машиной подключив ее на свободный порт и запустив tcpdump.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру