» Разбиение IP-сети на подсети разного размера

Дано: (простите, если слишком подробно буду излагать)

Провайдером выделена сеть реальных IP-адресов x.x.x.192/27, т.е. с x.x.x.193 до x.x.x.222, маска подсети 255.255.255.224. Адрес x.x.x.193 он занял под шлюз (АDSL-модем).
Имеется S - сервер доступа в Интернет, служащий маршрутизатором, файрволлом, считает траффик - т.е. все нужно пропускать через него, кроме того, что в DMZ выносится. Соответственно он имеет два сетевых интерфейса - "наружу" и "вовнутрь" сети, скажем S1 и S2

Решение 1: Сеть разбиваем на 2 подсети x.x.x.193-206 и x.x.x.209-222, маска соответственно 255.255.255.240. Из первой, "внешней" подсети один IP присваиваем S1, "внутреннему" S2 присваиваем IP из второй, "внутренней" подсети. Остается 13 реальных IP-адресов для внутр. сети (в принципе хватит) и 12 адресов для внешней сети - это у нас получилась DMZ такая большая, реальные IP-адреса будут пропадать зря, они бы мне лучше "внутри" пригодились .

Решение 2: Разбить на 4 подсети - маска 255.255.255.248, получаются сети x.x.x.193-198, x.x.x.201-206, x.x.x.209-214, x.x.x.217-222. Первую сеть используем как в 1-м случае (остаются 4 IP адреса для DMZ) и имеем 3 подсети для внутренней сети. Берем, скажем, адрес x.x.x.201 из первой "внутренней" подсети для S2.

ВОПРОС: Можно ли все эти 3 подсети аггрегировать в одну большую, с одним адресом шлюза S2, т.е. x.x.x.201? На физическом уровне они будут, естественно, в одной сети находиться, но как будет с маршрутизацией?. Будут ли они "видеть" друг друга и наружную сеть?

Или же придется для интерфейса S2 прописывать алиасы - скажем, x.x.x.209, x.x.x.217 и указывать их как шлюзы для 2-й и 3-й внутр. подсетей? Тогда внутренний обмен между подсетями пойдет через сервер - зачем его еще и этим грузить?

Какие будут соображения, коллеги?

Соображение такое- использовать маршрутизацию хостов без деления на подсети. Ессно, не технологично в плане поддержки этих самых таблиц маршрутизации, но делать можно все, что твоей душе угодно- "пропустить" белый IP через череду "серых" не проблема. И ip-адреса не потеряешь.

Redeemed

Цитата:

Какие будут соображения, коллеги?

Наличие реальных IP на внутренней сети является обязательным? Тем более, что ты собрался DMZ организовывать. Может проще оставить реальные адреса под DMZ, а внутреннюю сеть организовать на "частных" IP?

Redeemed

Цитата:

Или же придется для интерфейса S2 прописывать алиасы - скажем, x.x.x.209, x.x.x.217 и указывать их как шлюзы для 2-й и 3-й внутр. подсетей? Тогда внутренний обмен между подсетями пойдет через сервер - зачем его еще и этим грузить?

Чтобы объединить разные сети - нужен маршрутизатор. Без алиасов скорее всего не обойтись.

finist

Ты предлагаешь, как я понял, на всех хостах с реальными IP-шниками прописать статические таблицы маршрутов до каждого хоста? В принципе, пока у меня их немного, это может пройти.
Кстати, мне рассказывали, что в свое время в незабвенном Гласнете (ныне РОЛ) почти вся маршрутизация была так прописана :О

Duke Shadow

Да, необходимо, по крайней мере несколько реальных IP-шников внутри. Связано с дурацким механизмом синхронизации/репликации баз данных MS Access 97. Моя бы воля - давно бы уж списал бы это в утиль .

Valhalla

Вот и я чувствую, что не обойтись без алиасов . Посмотрел я информацию по supernetting-у - как я понял, процесс обратный разбиению на подсети, но тут не применить - из маски обратно уже бит не отобрать, не задев 1-ю, внешнюю подсеть.

В тут в принципе подумал, если уж нагрузка на S2 будет сильно большая, общение логических подсетей в одной физической сети можно и другим протоколом реализовать - IPX/SPX, скажем, только вот NetBIOS-запросы надо будет включать поверх него, а не через TCP/IP. Хотя тоже сеть грузить..

Спасибо всем ответившим !

Redeemed

Цитата:

Связано с дурацким механизмом синхронизации/репликации баз данных MS Access 97.

Можно об этом поподробнее? Ты синронизируешь БД с кем-то за пределами своей сети или внутри?

ooptimum

Синхронизация с базой за пределами сети, конечно. Для этого нужен хотя бы один IP-адрес для сервера баз данных.
Схема там вообще какая-то жуткая, я и сам толком не вникал, как она действует, поскольку не я ее делал. Задействован MS Access Replication Manager, несколько реплик базы, там же где-то жестко вбит IP-адрес сервера БД. При этом к нему необходим доступ по http и ftp - там спец.папка создается ftpsynch, куда и выгружаются апдейты базы. В общем, на сервере БД еще и IIS держать приходится, и файрволлом закрывать доступ для всех, кроме участников синхронизации.