ARP, routers, order of resolving

[KYKAH]

А еще можно забацать маскарадинг для левой сетки.

ась?

По БСД-шному - NAT.
В левой сети gateway будет 192.168.0.11
Средний компьютер будет транслировать пакеты таким образом, что справа они будут иметь исходящий IP 192.168.0.10 а обратные пакеты передавать обратно на хосты, которые надо.

Побудем занудой

NAT не равен MASQ
MASQ это только частный случай NAT-a, да и к этому утверждению можно даже придраться, если еше нащать думать про SNAT, DNAT, PAT...

Кстати, с чего вы взяли, что NAT это BSD-шный термин?

[KYKAH]

А вот еще проблемка.
Ситуация такая:
Red Hat 9

Code: Select all

192.168.0.20------192.168.0.11+192.168.0.10-----192.168.0.25+INTERNET
                     |
192.168.0.30--|
                     |
192.168.0.40--|

Слева подсетка посредине гейтвей.

Нету слева подсетки, так как subnet должен иметь subnet mask, ее у вас нету

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

ip_forwarding тут включать нет смысла, так как по-хорошему network layer zdes' работать не будет. Можно конечно изврашатся с роутингом с субнет маской /32 но я даже не знаю, как такой изврат назвать...

Как уже правильно заметили, это будет работать только в bridge mode то есть на втором уровне, но тада ip_forwarding вообше не в кассу.

Мой совет, продумайте design, потом делайте implementation, Иначе это будет nightmare.
Мой quick solution: гуглить +"subnet calculator"

[KYKAH]

Ну скажем, когда ньюс сервер допускает по ИП - как быть если ИП у всех одинаковый?

Ээх, вам бы сначала почитать литературу типа "network for dummies"
Не злитесь, но похоже что вы не очень понимаете о чем люди говорят...
Мой вам совет: бобейте вашу сеть на НАСТОЯШИЕ сабнеты, измените роутинг (или попросите изменить) на роутере провидера, иначе вы получите такого монстра, что я даже врагу не пожелаю.
Совет искренний...
Готов помочь в design-e в рамках форума

[KYKAH]

Может пригодиться или наведет на нужную мысль:

Тред с http://www.ussg.iu.edu/hypermail/linux/kernel/0004.2/0573.html

Ну да, можно прокси-арпить IP роутера на внутреннем интерфейсе роутера/бриджа/сам-не-знаю-чего, а также прокси-арпить ИП адреса внутренних клиентов на внешнем интерфеисе этого же устройства.

Но я начинаю рвать волосы на теле, когда думаю об этом...
Наверное убил бы клиента который бы сделал что-либо подобное.

Ндаа, будет ли при этом работаь broadcast???

[IP]

А еще можно забацать маскарадинг для левой сетки.

ась?

По БСД-шному - NAT.
В левой сети gateway будет 192.168.0.11
Средний компьютер будет транслировать пакеты таким образом, что справа они будут иметь исходящий IP 192.168.0.10 а обратные пакеты передавать обратно на хосты, которые надо.

Не годится!

А по-другому - никак. Нельзя сажать адреса с одной подсети на разные адаптеры (а у Вас сеть-то одна)
Разделите сетки (скажем слева сделайте 192.168.1.ххх) и "читайте документацию".

[KYKAH]

Разделите сетки (скажем слева сделайте 192.168.1.ххх)...

Нее, это явный перебор, так как вынудит делать NAT, нужно просто побить существующую сеть 192.168.0/24 на несколько подсетей /25 или /26, а лучше /28

Хотя я, пожалуй, погорячился, если 192.168 реальный ip-space aFigLi, то можно сабнетов городить сколько угодно.

[f_evgeny]

А еще можно забацать маскарадинг для левой сетки.

ась?

По БСД-шному - NAT.
В левой сети gateway будет 192.168.0.11
Средний компьютер будет транслировать пакеты таким образом, что справа они будут иметь исходящий IP 192.168.0.10 а обратные пакеты передавать обратно на хосты, которые надо.

Не годится!

А по-другому - никак. Нельзя сажать адреса с одной подсети на разные адаптеры (а у Вас сеть-то одна)
Разделите сетки (скажем слева сделайте 192.168.1.ххх) и "читайте документацию".

Иногда бывает затруднительно менять существующее разбиение. Тогда, как я уже писал выше, вполне работающее решение - роутить на каждый хост отдельно.

[f_evgeny]

А еще можно забацать маскарадинг для левой сетки.

ась?

По БСД-шному - NAT.
В левой сети gateway будет 192.168.0.11
Средний компьютер будет транслировать пакеты таким образом, что справа они будут иметь исходящий IP 192.168.0.10 а обратные пакеты передавать обратно на хосты, которые надо.

Побудем занудой

NAT не равен MASQ
MASQ это только частный случай NAT-a, да и к этому утверждению можно даже придраться, если еше нащать думать про SNAT, DNAT, PAT...

Кстати, с чего вы взяли, что NAT это BSD-шный термин?

Вы действительно занудствуете
Не надо лишних подробностей, чтобы не путать людей.
А про BSD я имел в виду то, что традиционно, то что делали на Линуксе при помощи маскарадинга, на БСД делали при помощи НАТ.

[A. Fig Lee]

А вот еще проблемка.
Ситуация такая:
Red Hat 9

Code: Select all

192.168.0.20------192.168.0.11+192.168.0.10-----192.168.0.25+INTERNET
                     |
192.168.0.30--|
                     |
192.168.0.40--|

Слева подсетка посредине гейтвей.

Нету слева подсетки, так как subnet должен иметь subnet mask, ее у вас нету

Она есть, но не нарисована. 255.255.25.0

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

Если б я делал дизайн, я б так глубоко не копал.
Суть дела - надо иметь четкое ПОНИМАНИЕ всего, что происходит и влияет.
Сеть не наша, нас там нет. Наш - гейтвей, который пытаются воткнуть и пропадает соединение. Гейтвей можно кофигурить как бридж, так и раутер.
Дальше-больше .. Таких клиентов у нас много, у всех сети разные и часто более сложные чем изображенная. Как правило у нас на гейтвее минимум 3 карточки. показан простой вариант. клиенты обидчивые - если он поставил и не заработало он грит - гейтвей ваш никуда не годится. Пример - вчера не было коннекшна между 2-я мачинами, ну хорошо, сабнеты разные, но там же обычный кабель воткнули, не кроссовер. Хорошо клиент быстро в сознанку пошел.
Задача мне - мягко, нежно, с любовью в голосе ПО ТЕЛЕФОНУ (как правило без коннекшн - посмотреть ничего нельзя), обьяснить клиенту КАК надо в его случае.
Надеюсь, теперь понятны исходные данные? Ето один из вариантов похожих на клиента, которые я тестировал.
В идеале надо написать скрипт короый бы спрашивал клиента и кофигурил гейтвей сам

ip_forwarding тут включать нет смысла, так как по-хорошему network layer zdes' работать не будет. Можно конечно изврашатся с роутингом с субнет маской /32 но я даже не знаю, как такой изврат назвать...

В смысле - а как без IP_FORWARDING?
Не работает если не бридж.
А раутинг с /32 мы так постоянно и прописуем.

Как уже правильно заметили, это будет работать только в bridge mode то есть на втором уровне, но тада ip_forwarding вообше не в кассу.

А у меня без бридхза с левой стороны работает, только с права бридж.

[A. Fig Lee]

Ну скажем, когда ньюс сервер допускает по ИП - как быть если ИП у всех одинаковый?

Ээх, вам бы сначала почитать литературу типа "network for dummies"
Не злитесь, но похоже что вы не очень понимаете о чем люди говорят...

Как о чем?
Там между прочим - реальные IP, не 192.168, если Вы об етом.
Иначе я не понимаю. Какой раздел хоть читать?

[A. Fig Lee]

А еще можно забацать маскарадинг для левой сетки.

ась?

По БСД-шному - NAT.
В левой сети gateway будет 192.168.0.11
Средний компьютер будет транслировать пакеты таким образом, что справа они будут иметь исходящий IP 192.168.0.10 а обратные пакеты передавать обратно на хосты, которые надо.

Не годится!

А по-другому - никак. Нельзя сажать адреса с одной подсети на разные адаптеры (а у Вас сеть-то одна)
Разделите сетки (скажем слева сделайте 192.168.1.ххх) и "читайте документацию".

Как нельзя? Мы же сажаем и работает?
Ех, предупреждал меня китаец - гуру по файрволлам и т.д., что бридж мод мало кто знает.

[A. Fig Lee]

Не надо лишних подробностей, чтобы не путать людей.
А про BSD я имел в виду то, что традиционно, то что делали на Линуксе при помощи маскарадинга, на БСД делали при помощи НАТ.

Как ето не надо?
Колитесь!

[Strannik223]

Как нельзя? Мы же сажаем и работает?
Ех, предупреждал меня китаец - гуру по файрволлам и т.д., что бридж мод мало кто знает.

Что то я не понимаю
Если оно работает то что мы тут обсуждаем собственно
Ежели оно не пингуется, как вы писали выше, то как же это можно назвать "работает"???

Бридж действительно используется редко
Чем он лучше роутинга в вашей ситуации? Какая мотивировка?

[A. Fig Lee]

Как нельзя? Мы же сажаем и работает?
Ех, предупреждал меня китаец - гуру по файрволлам и т.д., что бридж мод мало кто знает.

Что то я не понимаю
Если оно работает то что мы тут обсуждаем собственно
Ежели оно не пингуется, как вы писали выше, то как же это можно назвать "работает"???

1. Обсуждаем принципы- почему работает или почему не работает.

Работает, но только когда я сделал правый (если я правильно помню) интерфейс на бридж. к тому же пришлось почему-то Бриджевать "алл", что я не понял до сих пор. Наверное, таки в сурс придется лезть.
Вот меня и интересовало как получилось что надо бриджевать. Сейчас разобрался вроде.

Бридж действительно используется редко
Чем он лучше роутинга в вашей ситуации? Какая мотивировка?

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

[KYKAH]

А вот еще проблемка.
Ситуация такая:
Red Hat 9

Code: Select all

192.168.0.20------192.168.0.11+192.168.0.10-----192.168.0.25+INTERNET
                     |
192.168.0.30--|
                     |
192.168.0.40--|

Слева подсетка посредине гейтвей.

Нету слева подсетки, так как subnet должен иметь subnet mask, ее у вас нету

Она есть, но не нарисована. 255.255.25.0

Correct me if I am wrong, но такой маски не может быть

[f_evgeny]

Correct me if I am wrong, но такой маски не может быть

Конечно, поскольку:
25 = 0b11001

[KYKAH]

Гейтвей можно кофигурить как бридж, так и раутер.

Gateway нельзя сконфигурить как bridge. Это по определению.

Дальше-больше .. Таких клиентов у нас много, у всех сети разные и часто более сложные чем изображенная. Как правило у нас на гейтвее минимум 3 карточки. показан простой вариант. клиенты обидчивые - если он поставил и не заработало он грит - гейтвей ваш никуда не годится. Пример - вчера не было коннекшна между 2-я мачинами, ну хорошо, сабнеты разные, но там же обычный кабель воткнули, не кроссовер. Хорошо клиент быстро в сознанку пошел.
Задача мне - мягко, нежно, с любовью в голосе ПО ТЕЛЕФОНУ (как правило без коннекшн - посмотреть ничего нельзя), обьяснить клиенту КАК надо в его случае.
Надеюсь, теперь понятны исходные данные?

Может я торможу, но ничего не понял

ip_forwarding тут включать нет смысла, так как по-хорошему network layer zdes' работать не будет. Можно конечно изврашатся с роутингом с субнет маской /32 но я даже не знаю, как такой изврат назвать...

В смысле - а как без IP_FORWARDING?
Не работает если не бридж.

И не будет, с вашими ишодными данными

А раутинг с /32 мы так постоянно и прописуем.

Ну и флаг вам в руки

Как уже правильно заметили, это будет работать только в bridge mode то есть на втором уровне, но тада ip_forwarding вообше не в кассу.

А у меня без бридхза с левой стороны работает, только с права бридж.

Чего? Не понял

[KYKAH]

Работает, но только когда я сделал правый (если я правильно помню) интерфейс на бридж. к тому же пришлось почему-то Бриджевать "алл", что я не понял до сих пор.

Чего бы это значило?

Наверное, таки в сурс придется лезть.

Ага, OSI 7-layer и Network Addressing

[KYKAH]

А вот еще проблемка.
Ситуация такая:
Red Hat 9

Code: Select all

192.168.0.20------192.168.0.11+192.168.0.10-----192.168.0.25+INTERNET
                     |
192.168.0.30--|
                     |
192.168.0.40--|

Слева подсетка посредине гейтвей.

Нету слева подсетки, так как subnet должен иметь subnet mask, ее у вас нету

Она есть, но не нарисована. 255.255.25.0

Ув. A. Fig Lee!
Даже предполагая то, что вы ошиблись и имели ввиду 255.255.255.0 позволю вам обяснить некоторую фундаментальную вешь, без понимания которой все дальнейше рассуждения теряют смысл.

Ишодные данные: Gateway=router

Следователньно gateway <> bridge

это первое.
Второе,
Gateway соединяет как минимум дава RAZNYH сабнета.
Gateway, по определению, не может размешаться ВНУТРИ субнета.
Если устройство помешено внутри субнета, то максимально возможный уровень (OSI) этого устройства -- bridge. Следовательно изначальное условие поставленно некорректно

[A. Fig Lee]

А вот еще проблемка.
Ситуация такая:
Red Hat 9

Code: Select all

192.168.0.20------192.168.0.11+192.168.0.10-----192.168.0.25+INTERNET
                     |
192.168.0.30--|
                     |
192.168.0.40--|

Слева подсетка посредине гейтвей.

Нету слева подсетки, так как subnet должен иметь subnet mask, ее у вас нету

Она есть, но не нарисована. 255.255.25.0

Ув. A. Fig Lee!
Даже предполагая то, что вы ошиблись и имели ввиду 255.255.255.0 позволю вам обяснить некоторую фундаментальную вешь, без понимания которой все дальнейше рассуждения теряют смысл.

Ишодные данные: Gateway=router

Следователньно gateway <> bridge

это первое.
Второе,
Gateway соединяет как минимум дава RAZNYH сабнета.
Gateway, по определению, не может размешаться ВНУТРИ субнета.
Если устройство помешено внутри субнета, то максимально возможный уровень (OSI) этого устройства -- bridge. Следовательно изначальное условие поставленно некорректно

1. Gateway - ето gateway (gate+way). Раутер - ето раутер, грубо говоря частный случай гейтвея.
2. В теории ОСИ все прекрасно, мне практика нужна.
3. По поводу предыдущих недоразумений что Вы непоняли:
бридж интерфейса:
http://www.tldp.org/HOWTO/Wireless-HOWTO-10.html
Бриджевать "all"
echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp


http://www.netbook.cs.purdue.edu/othrpags/qanda136.htm

[KYKAH]

1. Gateway - ето gateway (gate+way). Раутер - ето раутер, грубо говоря частный случай гейтвея.

Это неправильно, смотрите ниже.
Люблю, когда люди сами себе терминологию придымывают..
Советую в следующий раз употреблять какое-нибудь другое слово, которое "more generic" : multihomed system, например

2. В теории ОСИ все прекрасно, мне практика нужна.

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

3. По поводу предыдущих недоразумений что Вы непоняли:
бридж интерфейса:
http://www.tldp.org/HOWTO/Wireless-HOWTO-10.html
Бриджевать "all"
echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp

Да, я не понял!
Речь в вашей ссылке идет о Proxy ARP а не о "bridging interfejsa".
Надо понимать это слово в контексте, так как это в стате описывается вроде как "network hack".
Где есть bridging, там нету масок /32 и нет IP адресов.

http://www.netbook.cs.purdue.edu/othrpags/qanda136.htm

Теперь прочитайте свою же ссылку еще раз.
И еще раз.
А потом вчитайтесь в ключевое слово "heterogeneous"

[A. Fig Lee]

КУКАН, спасибо за плодотворную помощь.
У меня нет ни времени ни желания чегото доказывать, приводить ссылки по бридж/proxy_arp, где какие термины применять и так далее.

Вобщем, Вы во всем правы. thank you.

[KYKAH]

КУКАН, спасибо за плодотворную помощь.
У меня нет ни времени ни желания чегото доказывать, приводить ссылки по бридж/proxy_arp, где какие термины применять и так далее.

Вобщем, Вы во всем правы. thank you.

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

И ссылки мне не надо приводить, так ваши же ссылки показывают что вы неправы, но признавать этого не хотите.

В-обшем, не хотел бы я оказаться в роли вашего клиента, вот и все.

[Tango]

Correct me if I am wrong, но такой маски не может быть

Конечно, поскольку:
25 = 0b11001

My $0.02: Вообще-то, в теории IPv4 eto валидная маска (Маска и только она определяет какие bit'ы - subnet а какие host..., и они необязательно должны быть вместе). На практике-же так никто не делает.

И, насчет терминов о layer-2/layer-3 switching: (во многих кругах) layer-2 device обычно зовется "switch" (и реже "bridge"); layer-3 device-"router". В моем понимании, "gateway" ето скорее термин сетевой иерархии (типа, окно на более высокий уровень internetworing, a "router" ето "функциональное" определение: device, которыи доставляет ("routit") пакеты до следующего router'a.