Добрый день. Такая ситуация, никак не пойму, почему происходит такая ситуация.Имеется две линукс-машины. Настроены на одну сеть, все нормально, друг друга видят. Предположим, что машины имеют адреса 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го уровня? Заранее всем спасибо.
что на удаленной с promiscuous режимом (при запуске tcpdump он включается автоматом)?ваще сетевая карта (железка) в обычном режиме игнорит все кроме щироковещательных и своих eth-фреймов, бродкасты может принимать (кстати статически неверный адрес бродкастом не является?)
при promiscuous принимаются все пакеты и в этом случае линух может захавать и с кривым маком, т.к. IP совпадает (так ли точно не наю). Может есть настройка в /proc/... включающаая более строгий режим.
>что на удаленной с 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/... включающаая более строгий режим.
Ну вот где бы эту настройку найти и понять как она работает...
>>что на удаленной с 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 и стандарты ((
Спасибо, попробовал просто поменять в правильном адресе сетевухи последний бит - та же картина.Начал проводить исследование дальше. Смотрю теперь тцпдампом на принимающей машине, что происходит. Режим промискус отключил опцией -p тцпдампа. Так вот, что интересно. У меня между этими линуксами стоят свитчи Allied Telesyn разные, например 8024.
Так вот, смотрю на машине-отправителе, где чуток поправлен мак-адрес второй машины. Пакет уходит с неправильным маком (поменял в маке последний байт на +1, например было 00-15-e9-40-0e-4c, я вбил 4d). А на целевой машине пакет приходит уже со всеми верными реквизитами! И вторая машина отвечает уже на верный мак! Такое впечатление, что свитч сам просматривает свои таблицы мак-адресов на предмет совпадений ИП-адресов и проставляет верные МАКи. Сегодня-завтра буду пробовать тупо соединить патчем два линукса и проверять без свитча между ними.
>Спасибо, попробовал просто поменять в правильном адресе сетевухи последний бит - та
>же картина.
>
>Начал проводить исследование дальше. Смотрю теперь тцпдампом на принимающей машине, что происходит.
>Режим промискус отключил опцией -p тцпдампа. Так вот, что интересно. У
>меня между этими линуксами стоят свитчи Allied Telesyn разные, например 8024.Ага!!! есть посредники =)))
[skip]
>Такое впечатление, что свитч сам просматривает свои таблицы
>мак-адресов на предмет совпадений ИП-адресов и проставляет верные МАКи.повторю свое зы:
p.s. иногда встречаются системы и устройства нарушающие и rfc и стандарты :))>Сегодня-завтра буду пробовать тупо соединить патчем два линукса и проверять без свитча между ними.
Будет интересно узнать как линух поведет себя. Свичи забракуем - че та они шибко умные =)
Подключал напрямую - все чисто, пинги пропадают, как только делаешь "неправильный" мак на машине с исходящими пакетами. Пробовал в тупой тренднет 5-портовый свитч втыкать - пакеты не пропадают, а приходят с верными маками. Я фигею, дорогая редакция...Ну не должны же свитчи 2го уровня себя так вести! Они ж ничего не знают о 3м уровне, держат только таблицу маков...Хотя приходит в голову решение...Свитч когда принимает неизвестный ему мак тупо бродкастит пакет во все порты. Далее линукс принимает этот пакет (вот тут уже непонятки начинаются, ибо нафига он его принимает???), делает arp who-has и отвечает уже на правильный полученный мак. Но тцпдамп вроде бы показывает что пакет УЖЕ приходит с правильным маком...А получается виноват только свитч...Т.е. судя по тцпдампу:
1. Приходит пакет с уже верными мак-ип
2. Сервер куда пришел пакет делает arp who-has
3. Сервер отвечает на верный ИП-МАК.
>Они ж ничего не знают о 3м уровне, держат только таблицу маков...
как бы..
>
>Хотя приходит в голову решение...Свитч когда принимает неизвестный ему мак тупо бродкастит
>пакет во все порты. Далее линукс принимает этот пакет (вот тут
>уже непонятки начинаются, ибо нафига он его принимает???), делает arp who-has
>и отвечает уже на правильный полученный мак. Но тцпдамп вроде бы
>показывает что пакет УЖЕ приходит с правильным маком...А получается виноват только
>свитч...Т.е. судя по тцпдампу:
>
>1. Приходит пакет с уже верными мак-ип
если так, то свич похоже анализирует IP адрес и правит MAC, надо на них спеку читать.
Разные свичи - разное поведение. Возможно работает на так сказать 2.5 уровне..
Наличие/отсутствие бродкаста у свича при приходе пакета с неверным МАК можно проверить третьей машиной подключив ее на свободный порт и запустив tcpdump.