Помогите разрулить провайдераские IP-адреса в локалку через сервер

времени нет ща вечером отпишусь но копай в сторону route, route add default gw **.**.**.**

1. Твердые адреса называются "Статическими". Так что хватит позориться. ;)

>RJ45 для связи с провайдером приходит на eth0. Я ему дал адрес 1.2.3.34

>Сетевая, ведущая в локалку, eth1 получила адрес 1.2.3.41

Слушай, ты шифровку пишешь или чего ты делаешь?

Значит, были у тебя адреса в инете вида xxx.xxx.xxx.33 - xxx.xxx.xxx.47

Теперь вопрос - в локальной сети у тебя были ДРУГИЕ адреса yyy.yyy.yyy.хз1 - yyy.yyy.yyy.хз2 или же ты у тебя всего 16 машин и на каждую за каким-то хреном на статику посадил? (Если винды стоят, тебе конец - у меня десяток машин впрямую стояли одно время - пока за NAT не отправил, мучался страшно.)


>Сеть пытаюсь настроить при помощи system-config-network из под Иксов.

Это ты погорячился.


>1. Файл ifcfg-eth0 (привожу, естественно основное).
>
>BROADCAST=1.2.3.39
>NETMASK=255.255.255.224
>NETWORK=1.2.3.32
>GATEWAY=1.2.3.33
>IPADDR=1.2.3.34

Скажи мне, милый человек, вот как теперь мы локальные от провайдера будем отделять в твоем вопрос от твоих локальных и твоих статических?

>NETMASK=255.255.255.224

Сам писал?

>2. Файл ifcfg-eth1
>BROADCAST=1.2.3.47
>NETMASK=255.255.255.240
>NETWORK=1.2.3.40
>GATEWAY=1.2.3.33
>IPADDR=1.2.3.41

Сетевой карте eth1 шлюз не нужен. Ты же не будешь с сервера посылать пакет ВНУТРЬ сети, чтобы выйти В ИНЕТ? Значит эта строчка должна быть пустой, а адрес, желательно, чтобы не входил в диапазон статических адресов, выданных провайдером - это лишнее и глупость.
Значит вместо него ты пропишешь 1.2.3.xx

>После активации интерфейсов компьютеры локалки (1.2.3.41, 1.2.3.42...) видят сервер (1.2.3.34, 1.2.3.41), однако ни в какую не хотят видеть желанный GATEWAY (1.2.3.33)

Вот этот 1.2.3.xx, о котором я говорил, будет шлюзом (gateway) для других машин, а вовсе не 1.2.3.33.

Пинговать, если я не ошибаюсь, они его и не должны (почитай, как там icmp роутится).

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

Вобщем, как все исправишь (и человеческим языком напишешь адреса, чтобы их можно было различать на письме), приходи еще.

>Итак, я пришел к решению разбить выделенные 16 адресов на две подсети по 8 адресов

1) не прокатит такой вариант с саброутингом или надо сначало прописать у прова на роутере что тем рядом аддресов что ты решил раздавать со второй карты заведует твой роутер иначе роутер прова будет долбится в пустоту

2) проще было бы сделать роутинг в таком варианте взять у прова 1 ип с одной подсети и скок тебе надо из другой подсети для раздачи (как пример у меня 1 из 195й и 6 из 213й подсетей разруливается на раз)

3) или как вариант попробовать збрать все адреса с помощю привязки к eth0 и всеь трафик завернуть в маскарадинг и раздавать адреса остальным через нат. Но если честно я не знаю осуществимо или нет такое, основная проблема в том чтобы исходящий трафик например .41 адреса уходил с .41 а не .33 .... если кто-то знает как осуществить фишку с трафиком на алиасаы расскажите самому интерестно))

На аплинк провайдера достаточно сетки /30: соответсвующий 
файл ifcfg-eth0
BROADCAST=1.2.3.35
NETMASK=255.255.255.252
NETWORK=1.2.3.32
GATEWAY=1.2.3.33
IPADDR=1.2.3.34

Файл ifcfg-eth1
BROADCAST=1.2.3.47
NETMASK=255.255.255.248
NETWORK=1.2.3.40
IPADDR=1.2.3.41

+ можешь добавить 
ifcfg-eth1:0
BROADCAST=1.2.3.39
NETMASK=255.255.255.252
NETWORK=1.2.3.36
IPADDR=1.2.3.37
в таком случае сможешь использовать 1.2.3.38 в своей сетке.
 

>1. Твердые адреса называются "Статическими"

Точно не "твердые", но и "статическими" я бы их не назвал :) Я имею ввиду, что "статическими" привык называть не динамически выдаваемые адреса, можно и вида 192,168,0,0/24

>На аплинк провайдера достаточно сетки /30: соответсвующий

Вы предвосхитили мои следующие вопросы. А именно на связь с провайдером я хотел выделить сетку из 4-х адресов: один - NETWORK, два - на сетевые интерфейсы, и последний - BROADCAST. Ну а оставшиеся 12 адресов я хотел запустить в локалку. В этой схеме смущает лишь одно - "кривое" число 12, не являющееся степенью двойки.
Хотя Ваше предложение тоже более экономно, чем у меня сейчас, распоряжается адресами.

ALL

Не думал, что моя проблема вызовет столь активную дискуссию. Один пост был даже жестким, хотя ИМХО я неплохо описал свою проблему...

Ну а пока пару ремарок (на практике все буду завтра испытывать).

1. Конечно, было бы идеально, если бы провайдер выделил нам gateway из одной подсетки, а остальные адреса - из другой. Раньше, с предыдущим провайдером так и было и я все настроил за 15 минут.

2. NAT не проходит. Люди, которым нужны постоянные IP-адреса, требуют абсолютно "честного" Интернета. То есть наш сервер должен исполнять роль обычного транзита.

3. Дело даже не в "твердых" и "нетвердых" IP-адресах. Я ведь на разных интерфейсах сейчас имею две непересекающиеся подсетки с одним GATEWAY 1.2.3.33 А при команде ping (tracert) адреса 1.2.3.33 он почему-то ищется за 1.2.3.41, а не за 1.2.3.34
Пробовал я ставить GATEWAY 1.2.3.34 - тоже бесполезно...
Так что проблема пока состоит в том, чтобы сервер стал искать адрес 1.2.3.33 и внешние адреса за 1.2.3.34, а не за 1.2.3.41...

4. Подозрения, конечно, падают на скрипты system-config-network
Думаю, что они жестко завязаны на "правильные" сети - класса A, B, C.
То есть NETMASK=255.255.255.0 и BROADCAST=1.2.3.255 они понимают, а вот более мелкие сети, нежели класс С, - нет.

Поэтому план таков.
А. Интерфейсы поднимаю при помощи system-config-network.
Утилитой route чищу таблицу маршрутизации и руками создаю ее сам. Смотрю, что из этого выйдет.
Б. Если по п А. ничего не выйдет, то руками еще поднимаю и интерфейсы...

В общем, проблем будет хватать, ибо имею минимальный опыт "работы руками" с утилитами ifconfig и route. Что поделать, разработчики Linux делают ОС все более кнопочной (как Винда). И скрипты автонастройки все глубже внедряются в глубины ОС (ИМХО).

P.S. Что касается принципиальной возможности успешной настройки ОС в моем случае, то техсуппорт провайдера уверяет - все возможно и все просто. Им можно верить, ибо провайдер - Corbina Telecom - далеко не самый мелкий.

Не надо ничего выдумывать, а просто сделать как я предложил, после service network restart все заработает. Ваши проблемы с ping и tracert из-за пересекающихся сеток на интерфейсах.

p.s и не забыть net.ipv4.ip_forward=1 в /etc/sysctl.conf

Сначала исправь ошибки со шлюзами.

Что касается "честных" адресов - они-то непрофессионалы, я понимаю, а ты-то что?

NAT можно поднять легко.

На натовский интерфейс назначишь все ip-адреса. Далее прокинешь их в сетку на локальные адреса и точно так же заберешь обратно.

Вобщем, читай iptables-tutorial + faq.

P.S. И НЕ НАЗНАЧАЙ НА ВНУТРЕННИЙ ИНТЕРФЕЙС АДРЕС, ВЫДАННЫЙ ПРОВАЙДЕРОМ!!! НЕ нужен он там.

>Не надо ничего выдумывать, а просто сделать как я предложил, после service network restart все заработает.

Огромное спасибо за помощь. Действительно, я допустил ошибку в вычислении NETMASK для мелких сетей (я не просто последовал рекомендациям, но и понял причину своих неудач). Согласно вашим рекомендациям много чего заработало. Однако, не все.

1. По команде route -n действительно появились (наконец-то!) две сети:
1.2.3.32
1.2.3.40
и общий GATEWAY 1.2.3.33
Более того, с клиентской машины 1.2.3.42 все интерфейсы сервера видятся (1.2.3.34 и 1.2.3.41). Весь внешний Интернет с сервера видится.
Это положительный момент.

2. А теперь о предмете моих раздумий.
Адрес провайдера 1.2.3.33 видится с сервера
ping -I 1.2.3.34 1.2.3.33
ping -I 1.2.3.41 1.2.3.33
но не видится с клиента, находящегося за eth1, 1.2.3.42

Теперь решаю эту головоломку. Хотя согласен с ранее выступившими господами. Без провайдера эту проблему ИМХО не решить. Ему в своих роутерах надо указать, что сеть 1.2.3.32/255.255.255.240 на самом деле разбита на более мелкие сети, GATEWAY для которых является 1.2.3.34.

P.S. Кстати, провайдер сам ошибся, выдав нам сеть из 16 адресов 1.2.3.32/255.255.255.224 (на самом деле маска - 255.255.255.240).

Дорогой jackill, если человек сказал что ему не нужен NAT, то не нужно убеждать его в обратном :)

а у клиента за eth1 в качестве жлюза указан 1.2.3.41 ? Опять же, проверить, разрешен ли форвардинг на роутере и в настройке iptables . А провайдеру вовсе не нужно знать о вашей адресации :)

>To jackill

Я прекрасно понимаю, что делаю. С недавних пор в нашей организации появились люди, ведущие себя, мягко говоря, нечистоплотно. Они хотят полностью изолироваться от сотрудников IT организации и ваять собственный сайт, видимый из И-нета.
Поэтому я ничуть не расстроюсь, если этот твердый IP-адрес клиента хакнут... Обрадуются этому и многие руководители предприятия.
Так что хотят ответственности - пусть получают ее. Тем более, что все свои обильные web-сервисы они приземляют на Винде.

>To chucha

iptables -A FORWARD -s 1.2.3.40/255.255.255.248 -j ACCEPT
iptables -A FORWARD -d 1.2.3.40/255.255.255.248 -j ACCEPT

Тоже прописывал и для адреса 1.2.3.42 персонально

cat /proc/sys/net/ipv4/ip_forward
1

Да, ребята, гулять так гулять. Еще больше открою структуру нашей сети.
На самом деле интерфейс eth1 разделяется между сеткой 172.16.1.0/255.255.255.0 (eth1:0) и 1.2.3.40/255.255.255.248 (eth1:1). Кроме того, на серваке есть еще интерфейсы eth2 (172.16.3.0/255.255.255.0) и eth3 (172.16.2.0/255.255.255.0).

Теперь все это хозяйство видит друг друга, включая сеть 1.2.3.40 и адрес 1.2.3.34.
Немаршрутизируемые адреса 172.16.0.0 видят внешний И-нет через SNAT (--to-source 1.2.3.34). А вот адреса сетки 1.2.3.40 видят все, кроме 1.2.3.33 и, соответсвенно, Интернета.

ИМХО провайдерская проблема.