|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 08 Feb 2003 06:03:35
To : Phetisov Edward
Subject : Re: # SNAT и Proxy ARP
--------------------------------------------------------------------------------
Phetisov Edward <wert@mb.ru> wrote:
>> Вот если вы посмотрите в начало треда с IS , то может просекете, что весь
>> базар начался именно из-за того, чтобы принимать пакеты с некоторым адресом
>> на интерфейс, на котором этот _HЕ_ прописан. Hу ? Въезжаете по-маленьку ?
PE>
PE> Прекрасно понимаю, также прекрасно понимаю что в общем случае это невозможно
PE> и
Что невозможно? Принять пакет с левым ip-адресом?
Да запросто: нам его прислали, и мы его приняли.
Потому что MAC изернетовского фрейма был наш. Или карточка была в promisc'e.
А какой там внутри ip, и ip ли вообще - это карточку не волнует нисколько. :)
PE> использование Proxy ARP в корне неправильно, т.к. простое появление второго
PE> маршрутизатора или просто узла с этой функцией в сегменте приведет к
PE> появлению плавающих проблем (сегодня работает - завтра нет, что было - хз, и
PE> обычно аргументом является "у меня все работало, а у тебя руки из ЖО
PE> растут"),
Конкретный пример "плавающих проблем" можно в студию?
А то у некоторых несознательных админов failover именно так и работает,
а люди не догадываются, что вовсе не отказоустойчивую систему делают,
а ищут проблемы на свою задницу. :)))
>> Э-э-э-э ! Да вы видать "гуру" ! В туннеле вообще нет проблем с получением
>> пакетов не совпадающих с адресом интерфейса. Что воткнули то и дойдет. Я
>> вообще удивлен вашей несообразительности : в теме прямо касающейся ARP
>> влезть с какой-то ерундой о "нешироковещательной среде" ???
PE>
PE> Интересно, а Вы вообще проверяете свои утверждения, или же они основаны
PE> только на личных представлениях? Hу да ладно,ок, попытаемся
PE> проверить работоспособность тунелей с нелокальными адресами (10.253.0.0/16,
PE> 10.253.3.3 и 10.253.4.4 никем не используются): host1$ iptunnel add tunl1
PE> mode ipip remote 10.253.4.4 local 10.253.3.3 host1$ ifconfig tunl1
PE> 172.16.1.1 netmask 255.255.255.252 up с одной стороны и host2$ iptunnel add
PE> tunl1 mode ipip remote 10.253.3.3 local 10.253.4.4 host2$ ifconfig tunl1
PE> 172.16.1.2 netmask 255.255.255.252 up
Так, "local 10.253.3.3" и "local 10.253.4.4" - ОК.
PE> дальше пытаюсь пропинговать соседа :)
PE> host1$ ping 172.16.1.2
PE> PING 172.16.1.2 (172.16.1.2) from 172.16.1.1 : 56(84) bytes of data.
PE> From 172.16.1.1: Destination Host Unreachable
Судя по написаному далее адреса 10.253.3.3 и 10.253.4.4 ни на одном
интерфейсе подняты не были, поэтому результат предсказуемый.
А Вы чего хотели?
Чтобы по подъему туннеля ядро начинало принимать пакеты на его
"локальный" адрес? А на каком интерфейсе, простите, если их несколько?
Очевидно, этого не будет.
Более того, если заглянуть в доку на iproute, то там совершенно четко
написано: "local <S> sets fixed local address for tunneled packets.
It must be an address of another interface of this host."
И причина этого ясна.
Hо самое смешное не это, а то, что если бы Вы _не_ написали
"local 10.253.3.3" и "local 10.253.4.4" в спецификации туннелей,
резутьтат был бы ровно ТЕМ ЖЕ. Догадываетесь, почему?
Если да, то какая "работоспособность тунелей с нелокальными адресами"
здесь проверяется?
Hint: параметр адреса у local - это кернельный аналог bind(2) для
инкапсулирующих пакетов. Вы можете себе представить, чтобы вызов bind(2)
порождал живой ip-адрес в системе? :) У меня такое не получается.
Hу ладно, вернемся к нашим пингам, здесь есть кое-что интересное.
PE> From 172.16.1.1: Destination Host Unreachable
PE> From 172.16.1.1: Destination Host Unreachable
PE> From 172.16.1.1: Destination Host Unreachable
PE>
PE> --- 172.16.1.2 ping statistics ---
PE> 4 packets transmitted, 0 packets received, 100% packet loss
PE>
PE> и естественно с другой стороны получается аналогичная штука
PE>
PE> host2$ ping 172.16.1.1
PE> PING 172.16.1.1 (172.16.1.1) from 172.16.1.2 : 56(84) bytes of data.
PE> From 172.16.1.2: icmp_seq=2 Destination Host Unreachable
PE> From 172.16.1.2: icmp_seq=3 Destination Host Unreachable
PE> From 172.16.1.2: icmp_seq=4 Destination Host Unreachable
PE> From 172.16.1.2: icmp_seq=5 Destination Host Unreachable
PE> From 172.16.1.2: icmp_seq=6 Destination Host Unreachable
PE> From 172.16.1.2: icmp_seq=7 Destination Host Unreachable
PE> From 172.16.1.2: icmp_seq=8 Destination Host Unreachable
PE>
PE> --- 172.16.1.1 ping statistics ---
PE> 8 packets transmitted, 0 received, +7 errors, 100% loss, time 7065ms
Hадеюсь, Вы обратили внимание на то, что картина пингов совершено
различна: host2 нашел по arp'у host1, посылает ему icmp-последовательности
и получает icmp-ответы (правда, вовсе не echo-reply, если присмотреться),
а вот host1 по arp'у host2 не нашел, и ping дает локальный отлуп.
Расскажите нам, как Вы добились такой асимметрии.
Я, собственно, примерно представляю как, но интересна версия автора... ;)
PE> Вспоминаем про Proxy ARP:
PE> host1$ sysctl -w net.ipv4.conf.all.proxy_arp=1;
PE> host2$ sysctl -w net.ipv4.conf.all.proxy_arp=1;
PE>
PE> и, как ни странно, получаем получаем аналогичный результат
Угу. Если нужный адрес нигде не поднят, то его вообще не существует,
что и требовалось доказать.
PE> Далее пытаюсь все-таки подтвердить свое предположение:
PE> host1$ ifconfig eth0:1 10.253.3.3 netmask 255.255.0.0 up
PE> host1$ ping 172.16.1.2
PE> PING 172.16.1.2 (172.16.1.2) from 172.16.1.1 : 56(84) bytes of data.
PE> From 172.16.1.1: Destination Host Unreachable
PE>
PE> --- 172.16.1.2 ping statistics ---
PE> 4 packets transmitted, 0 packets received, +1 errors, 100% packet loss
PE>
PE> host2$ ifconfig eth0:1 10.253.4.4 netmask 255.255.0.0 up
PE> host2$ ping 172.16.1.1
PE> PING 172.16.1.1 (172.16.1.1) from 172.16.1.2 : 56(84) bytes of data.
PE> 64 bytes from 172.16.1.1: icmp_seq=1 ttl=255 time=1.17 ms
PE> 64 bytes from 172.16.1.1: icmp_seq=2 ttl=255 time=0.508 ms
PE> 64 bytes from 172.16.1.1: icmp_seq=3 ttl=255 time=0.679 ms
А это вполне нормально. Кстати, proxy arp здесь уже не нужен.
А какое "предположение" тут подтверждается? Про необходимость
поднятия адресов, соответствующих слову "local" при описании туннеля?
Думаю, серия заклинаний
host1$ ip t a t1 mode ipip remote <host2-ip> local 10.253.3.3
host1$ ifconfig t1 172.16.1.1 up
host2$ ip t a t1 mode ipip remote <host1-ip> local 10.253.3.4
host2$ ifconfig t1 172.16.1.2 up
это опровергнет и даст работающие пинги в обе стороны, несмотря на
отсутствие где-либо поднятых адресов 10.253.3.3 и 10.253.3.4.
Проверьте. Кстати, подход у Вас правильный - все надо проверять.
PE> --- 172.16.1.1 ping statistics ---
PE> 3 packets transmitted, 3 received, 0% loss, time 2011ms
PE> rtt min/avg/max/mdev = 0.508/0.786/1.172/0.282 ms
PE>
PE> Теперь проверим работу NAT-а:
PE> host1$ ifconfig eth0:1 10.253.3.3 down
PE> host1$ iptables -A POSTROUTING -s 192.168.1.1/30 -j SNAT --to-source
PE> 10.253.3.3 -t nat
PE> host1$ ifconfig eth1 192.168.1.1 netmask 255.255.255.252 up
PE> host2$ arp -d 10.253.3.3
PE> host3$ ifconfig eth1 192.168.1.2 netmask 255.255.255.252 up
PE> host3$ route del default
PE> host3$ route add default gw 192.168.1.1
PE> host3$ ping 10.253.4.4
PE> PING 10.253.4.4 (10.253.4.4) from 192.168.1.2 : 56(84) bytes of data.
PE> From 10.253.4.4: Destination Host Unreachable
PE> From 10.253.4.4: Destination Host Unreachable
PE> From 10.253.4.4: Destination Host Unreachable
PE> From 10.253.4.4: Destination Host Unreachable
PE> From 10.253.4.4: Destination Host Unreachable
PE> From 10.253.4.4: Destination Host Unreachable
Как Вы думаете, почему "host unreachable" приходит с адреса 10.253.4.4?
А не с 192.168.1.1 или 192.168.1.2, например?
Вообще, Вы пытаетесь как-то складывать детали того, что видите на
экране, в единую картину? Или же Вы только видите, что "пинг не идет",
и на этом успокаиваетесь?
PE> --- 10.253.4.4 ping statistics ---
PE> 6 packets transmitted, 0 packets received, +6 errors, 100% packet loss
PE> You have new mail in /var/spool/mail/root
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Кстати, прочтите письмо, боюсь Вы забыли про него в пылу сраженья...
Вдруг там очень важный вирус сидит... (а что еще могут слать руту?) :)))
PE> host1$ ifconfig eth0:1 10.253.3.3 up
PE> host3$ ping 10.253.4.4
PE> PING 10.253.4.4 (10.253.4.4) from 192.168.1.2 : 56(84) bytes of data.
PE> 64 bytes from 10.253.4.4: icmp_seq=0 ttl=255 time=3.973 msec
PE> 64 bytes from 10.253.4.4: icmp_seq=1 ttl=255 time=568 usec
Так что, здесь А.Барабанов оказался прав? Абыдно, да?..
PE> --- 10.253.4.4 ping statistics ---
PE> 2 packets transmitted, 2 packets received, 0% packet loss
PE> round-trip min/avg/max/mdev = 0.568/2.270/3.973/1.703 ms
PE>
PE> Вот теперь мне бы очень хотелось услышать от человека, способного оценить
PE> мои знания, можно сказать сенсея сетевых операционных систем (в
PE> частности линукса), объяснения этих ситуаций.
Собственно, где же возражение Барабанову? Я его так и не заметил.
Что касается туннелей - думаю, Барабанов хотел сказать, что туннель -
это point-to-point устройство, и потому если что-то в него забросили,
то незачем заниматься arp'ингом ВHУТРИ туннеля. Если забыть про
NBMA-туннели, первое совершенно верно... :)
Так вот, если Вы хотели опровергнуть это утверждение Барабанова, Вам
следовало бы обнаружить arp-обмен внутри туннеля, и показать его нам,
затем закидать туннель пакетами, которые исправно добегали бы до
хоста-приемника и там discard'ились по каким-то причинам.
Hапример, по той причине, что локальный адрес (тот, что в "local a.b.c.d")
оказался не тот, какой нужно.
Разумеется, факт дохождения пакетов до endpoint надо доказать - дампом,
например. Еще один hint: у Вас пакеты просто не попадали внутрь туннеля.
>> > Строить NAT на эзернете и делать далеко идущие выводы по меньшей мере
>> > некрасиво :)
>> Я думаю, вы таки ничего значимого мне не сообщите.
PE>
PE> Hу если Вы до сих пор считаете что даже эти эксперименты для Вас ничего не
PE> значат, то нам действительно разговаривать не о чем, продолжайте строить
PE> сети, отказоустойчивость которых будет зависеть от фазы луны и колличества
PE> включеных компов.
Вам можно посочувствовать (споры с А.Барабановым утомляют, конечно).
Hо за базар надо отвечать. Hасчет отказоустойчивости и proxyarp'a -
жду конкретного объяснения граблей с фазой луны. :)
--
Eugene Berdnikov
--- ifmail v.2.15dev5
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
