|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Phetisov Edward 2:5020/400 10 Feb 2003 20:31:56
To : Eugene B. Berdnikov
Subject : Re: # SNAT и Proxy ARP
--------------------------------------------------------------------------------
"Eugene B. Berdnikov" wrote:
> 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-таблице 30 минут, так что failover - то получитася, но
не
сразу, и строить на это отказоустойчивость, на мой взгляд, стоит только при
отстутствии или неприменимости других средств (яркий пример альтернативного
решения -
HSRP)
>
>
> >> Э-э-э-э ! Да вы видать "гуру" ! В туннеле вообще нет проблем с получением
> >> пакетов не совпадающих с адресом интерфейса. Что воткнули то и дойдет. Я
> >> вообще удивлен вашей несообразительности : в теме прямо касающейся ARP
> >> влезть с какой-то ерундой о "нешироковещательной среде" ???
> PE>
> PE> Интересно, а Вы вообще проверяете свои утверждения, или же они основаны
> PE> только на личных представлениях? Hу да ладно,ок, попытаемся
> PE> проверить работоспособность тунелей с нелокальными адресами
> PE> (10.253.0.0/16, 10.253.3.3 и 10.253.4.4 никем не используются): host1$
> PE> iptunnel add tunl1 mode ipip remote 10.253.4.4 local 10.253.3.3 host1$
> PE> ifconfig tunl1 172.16.1.1 netmask 255.255.255.252 up с одной стороны
> PE> и host2$ iptunnel add tunl1 mode ipip remote 10.253.3.3 local
> PE> 10.253.4.4 host2$ ifconfig tunl1 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у так я, собственно, опровергал предположение г-на Барабанова о том что "В
туннеле
вообще нет проблем с получением
пакетов не совпадающих с адресом интерфейса. Что воткнули то и дойдет" и
объяснения о
том, почему это не работает следовало бы давать ему :)
>
>
> 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> и, как ни странно, получаем получаем аналогичный результат
>
> Угу. Если нужный адрес нигде не поднят, то его вообще не существует,
> что и требовалось доказать.
>
:) см, выше
Пример с натом действительно был некоректен, так что думаю с этим примером
вопрос
будет закрыт
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
