Изоляция одной сети от другой. Необходим совет.

[DemonSKED]

Имеем:
10.0.0.1-10.0.3.255 - основная сеть
10.0.0.1/255.0.0.0 - основной шлюз сети
192.168.1.0/255.255.255.0 - сеть которая должна быть изолированна, но с доступом в интернет.
10.0.0.5/255.0.0.0(192.168.1.1/255.255.255.0) - сервер сети 192.168.1.0 (шлюз, ад, днс, нат и тп).

Интернет в сети 192.168.1.0 после настройки службы маршрутизации есть, через нат. Но эта сеть через этот же нат свободно ходит в сеть 10.0.0.0-10.0.3.255.

Вопрос:
Как можно запретить хождения в 10.0.0.0-10.0.3.255?

Я предполагаю, что нужно смотреть в сторону встроенного фаера. Но не знаю как правила там зарулить. Если судить из моего опыта во фре то нужно писать запрет на входящие подключения от 192.168.1.0 к 10.0.0.0-... по всем протоколам и портам. Проверить сейчас не могу - рулю сервером удаленно, а 192.168.1.0 сейчас вся выключена.

Надеюсь получить помощь. Заранее спасибо.

[QRS]

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

[Safety1st]

DemonSKED, я FreeBSD совсем не умею управлять, но если Вы "рулили сервером во фре", то это по ходу несложно. Исхожу из предположения, что "рулят" обычно сисадмины, а не эникейщики или пользователи, знающие больше других и кажущиеся себе сисадминами. Почему у меня возникло такое ощущение? NAT - это зло, которое мы вынужденно используем в силу ограниченности числа глобально маршрутизуемых IP-адресов (обычные люди называют их "внешними" или "публичными :)), а вы сетку 192.168.1.0/24 поместили за целыми 2-мя NAT, что является крайне нерекомендуемой конфигурацией, используемой только по незнанию. На сервере 192.168.1.1 NAT не нужен, просто маршрутизация должна быть сделана.

Для этого нужно:
a) удалить протокол маршрутизации NAT на сервере
b) на маршрутизаторе 10.0.0.1 указать маршрут до сети 192.168.1.0/24

После этого можно 'изолировать':
IPv4->General; выбираете интерфейс 192.168.1.1; Свойства->Кнопка ''Входящие фильтры..." (Inbound Filters...):
Новый, Сеть назначения, IP 10.0.0.0, маска 255.63.0.0 (закрывает диапазон 10.0.0.1-10.0.3.255) либо для простоты IP 10.0.0.0 и маска 255.0.0.0 (закрывает всё на 10.x.x.x), все протоколы, Ok, переключатель оставляем на "Принимать все пакеты, кроме ...".

[DemonSKED]

Isotonic,
Жаль что у вас сложилось впечатление обо мне такое. Ну вот нравится мне фраза рулю, а не администрирую. А двойные нат, ну так мне вообще не особо дают руки распускать, так как администраторов нас два, причем второй протеже начальника и его решения "по умолчанию верные".
Ваш совет приму к сведению. Видимо вы делали такое, так как выглядит весьма убедительно. Мне последние пару лет приходилось заниматься фрёй.
Сама идея как оно должно блокироваться мне пришла верная ведь.

[Safety1st]

Не, я имел ввиду 'рулю' не синонимом к 'администрирую' в том контексте. А - 'управляю, имея права, навыки и знания для этого'. Рулю - это звучит гордо, когда не просто как-то настраиваешь, а с пониманием, как это работает и как это должно быть настроено. Извините, что резко среагировал. Вы развеяли это впечатление.

По моему определению 'рулит' Ваш коллега, хотя бы потому что прав у него больше :) Жаль, если единственное объяснение этого для Вас - что протеже. Вы можете просто не видеть других причин со стороны руководства. Или он несправедливо считается более опытным? В любом случае, если хотите что-либо изменить - нужно что-то делать.

Начните с NAT.

Вы пробовали обращаться к коллеге за помощью? Или стараетесь по возможности скрывать от него свои незнания каких-то моментов? (как подавляющее большинство делает). Если он действительно шарит, он не сможет назвать ни одной причины против одной NAT вместо 2-х. А у Вас при себе готовый список плюсов.

А вдруг админ/руководство считают, что Вы слабее, чем Вы есть? Я бы тоже такому админу не давал руки распускать. Тогда нужно себя начинать зарекомендовывать соответственно уровню. Выход есть всегда.

Сама идея как оно должно блокироваться мне пришла верная ведь. »
Верная. Но это маленькое достижение, чтобы им гордиться :)

[DemonSKED]

Единственное объяснение что протеже потому что, он со мной спорил что если настроена маршрутизация и нат то сеть 192.168.1.0 не может видеть остальную сеть. Ну вот не должна она видеть. И начальник тоже самое заявил. И тут возникает вопрос-они правы? По моему нет, или я совсем ничего не понимаю и пора вооружиться кипой книг и все читать заново.
Подумав и все взвесив сегодня отрублю нат по вашему совету, он действительно там не нужен. Потом отпишусь.

[DemonSKED]

Эх, все не как у людей. Добрался до щлюза. Отрубил нат, настроил фильтр, маршрут прописали они по моей просьбе на 10.0.0.1 (меня не пускают к нему). Все работает по совету Isotonic.
Но тут другое добавилось, один сервер нужно открыть в сети 192.168.1.0 как это сделать фильтрами не понимаю. Надеюсь на совет. Плохой я администратор windows...
Вот в Ipfw все просто add deny all from 192.168.1.0/24 to 10.0.0.0/255.36.0.0, add allow all from 192.168.1.0/24 to 10.0.0.20.

[Safety1st]

то сеть 192.168.1.0 не может видеть остальную сеть »
Это неконкретная формулировка без специальной сисадминской терминологии. Что значит 'видеть' в данном контексте? Видеть в списке сетевого окружения? :) Вы сами в начале писали: "Но эта сеть через этот же нат свободно ходит в сеть 10.0.0.0-10.0.3.255. »
Выходит, NAT 'изоляции 192.168.1.0/24' (запрета хостов сети 192.168.1.0/24 общаться с хостами сети 10.0.0.0/14) не помогает. Он помогает в другом случае - из сети 10.0.0.0/14 никто не может пробиться к 192.168.1.0/24, но не наоборот. Потому что 'двери на вход' с сети 10.0.0.0/14 (временное сопоставление внутреннего адреса и порта и внешнего адреса и порта) открываются только по требованию хостов 192.168.1.0/24. Они т.о. не правы.

один сервер нужно открыть в сети 192.168.1.0 как это сделать фильтрами не понимаю »
Ура! Вы теперь уже не говорите 'встроенный фаер' :) У RRAS-фильтров ограниченные возможности: запретить всё, кроме, или разрешить всё, кроме. Вам же теперь нужно запретить всё, кроме, но с исключением. Здесь уже не легко и просто, потому что одновременно в фильтре нельзя иметь и разрешающие, и запрещающие правила с отработкой в порядке приоритета...

К сожалению, я по-другому понял выражение 'один сервер нужно открыть в сети 192.168.1.0': подумал, что компам сети 10.0.0.0/14 'один сервер нужно открыть в сети 192.168.1.0'. Поэтому, всё что в '----' относится к тому случаю, переписывать не вариант :) :

----

Компам сети 10.0.0.0/14 нужно будет, например, через DHCP разослать маршрут до сети 192.168.1.0/24, чтобы они знали, через какой маршрутизатор доступен сервер 192.168.1.x. Так точно будет работать. Но сначала можно попробовать и без этого: по идее, порядочные роутеры должны отправлять ICMP redirect с адресом 'правильного' маршрутизатора для пересылки, а порядочные хосты (если firewall не блокирует) реагировать на такие пакеты.

Я не меньше 2-х часов думал, как извратиться в этом случае. Не такой уж это простой вопрос в силу ограничений :)
Предлагаю следующее. Общая концепция: меняем одно правило широкого диапазона на ряд более узких, которые закрывают доступ к 10.0.0.0/14 для всех хостов, кроме 192.168.1.1-192.168.1.4, которые и будут выделены в качестве адресов для серверов. На DHCP нужно исключить эти адреса из выдачи и создать резерв для этого одного 'сервера' (или задать на хосте статические настройки, но тогда по настройкам будет видно, что он 'избранный').
Правила создавать на том же фильтре, что и ранее:

Сеть назначения: IP 10.0.0.0, маска 255.63.0.0 либо IP 10.0.0.0 и маска 255.0.0.0

Исходные сети (для каждого правила свои) + 'все протоколы':
сеть 192.168.1.128 маска 255.255.255.128 (закрывает 192.168.1.128-192.168.1.255)
сеть 192.168.1.64 маска 255.255.255.192 (закрывает 192.168.1.64 -192.168.1.127)
сеть 192.168.1.32 маска 255.255.255.224 (закрывает 192.168.1.32 -192.168.1.63)
сеть 192.168.1.16 маска 255.255.255.240 (закрывает 192.168.1.16 -192.168.1.31)
сеть 192.168.1.8 маска 255.255.255.248 (закрывает 192.168.1.8 -192.168.1.15)
сеть 192.168.1.4 маска 255.255.255.252 (закрывает 192.168.1.4 -192.168.1.7)

Чтобы ограничить и хосты 2-3 в обмене, нужно дополнительно указывать несколько правил именно для них:
сеть 192.168.1.2 маска 255.255.255.252 (закрывает 192.168.1.2 -192.168.1.3)
но использовать не 'все протоколы', а только так, чтобы закрыть всё, кроме нужного.

----

Для случая 'один сервер нужно открыть в сети 10.0.0.0/14 для сети 192.168.1.0/0' это тоже подходит: правим только 'сеть назначения' по аналогии, так чтобы неблокированным остался маленький диапазон, куда и поместить целевой сервер. Над комбинациями сеть/маска думайте сами :)

Как в Ipfw RRAS не может. Может TMG (бывший ISA).


Я бы изолировал сеть 192.168.1.0/24 не вообще, а только избирательно бы блокировал то, что не нужно, по ключевым точкам входа. Например, конкретные порты UDP 138,139, TCP 135, 137, 445 и т.д. Что значит 'ключевые': заблокировать TCP 135 - полностью прикрыть весь RPC-трафик. Это не так жёстко, но может быть достаточно. Какие-то порты перечислены здесь (http://support.microsoft.com/kb/832017). Главное, что тогда более гибко можно фильтры настраивать. Нас уже не ограничивают правила RRAS.

[DemonSKED]

Цитата DemonSKED: то сеть 192.168.1.0 не может видеть остальную сеть » Это неконкретная формулировка без специальной сисадминской терминологии. Что значит 'видеть' в данном контексте? Видеть в списке сетевого окружения? Вы сами в начале писали: " Цитата DemonSKED: Но эта сеть через этот же нат свободно ходит в сеть 10.0.0.0-10.0.3.255. » Выходит, NAT 'изоляции 192.168.1.0/24' (запрета хостов сети 192.168.1.0/24 общаться с хостами сети 10.0.0.0/14) не помогает. Он помогает в другом случае - из сети 10.0.0.0/14 никто не может пробиться к 192.168.1.0/24, но не наоборот. Потому что 'двери на вход' с сети 10.0.0.0/14 (временное сопоставление внутреннего адреса и порта и внешнего адреса и порта) открываются только по требованию хостов 192.168.1.0/24. Они т.о. не правы.
Именно.
За ваш совет спасибо. Все получилось. Почерпнул многое для себя. Оговорюсь еще раз - от адмнистрирования windows отошел года 4 назад все напрочь забыл занимаясь freebsd. Учусь заново, вспоминаю.
Кстати о TMG, а она разве не только под x64? Ибо сервер щел из коробки с x32.

[Safety1st]

Кстати о TMG, а она разве не только под x64? »
Не уточнял, скорее всего. Для меня давно стандарт: сервер - значит x64.

[Kiber]

Извращенцы :) Вы бы еще vpn подняли для разграничения :)
Не легче-ли для нужных компьютеров определить по второму ip-адресу, например:
Юзеру в 192.168: 172.16.1.*/24
Серверу в 10.0: 172.16.2.*/24
На маршрутизаторах соответственно прописать маршруты и фильтры, содиняющие только указанные ip адреса.
Ну и юзер должен обращаться к серверу по другому ip адресу.
При желании для этого можно использовать статичные DNS записи (можно даже завести отдельную зону, например static.local), у юзера и сервера ведь разные DNS сервера?

Собственно, если доступ из 10 сети к юзеру ограничивать не требуется, то можно не прописывать второй ip для сервера.
Ну, и возможно потребуются статические маршруты, чтобы клиент отправлял пакеты с нужного интерфейса. Хотя когда оба ip на одном интерфейсе это, возможно, и не потребуется.
У меня сейчас вообще забавная схема работает - от клиента до сервера пакеты идут через маршрутизатор, а возвращаются напрямую :). Без маршрутов, оба ip сервера на одном фейсе.

Хотя, при двух ip адресах на одном фейсе может возникнуть неоднозначность при обработке пакета маршрутизатором и применении фильтров.
Поэтому правильнее будет добавить пользователю сетевушку, дать ей ip из сети 172.16.1.*/24, прописать маршрут до сервера через эту сетевушку.

Есть вариант еще проще - Юзеру вместо 192.168 присваивается 172.16.1, и он работает исключительно с этого ip. Маршруты на маршрутизаторах всеравно потребуются, но зато не потребуется локальный маршрут.

P.S. Извиняюсь за сумбурность. Понравившийся вариант можем разобрать подробнее.

[exo]

поместили за целыми 2-мя NAT, что является крайне нерекомендуемой конфигурацией, используемой только по незнанию. »
ваши аргументы?

10.0.0.1-10.0.3.255 - основная сеть »
1022 хоста, у вас реально столько машин?
Тогда возможно у вас маршрутизатор и коммутаторы поддерживают VLAN ? Какие у вас модели?

[Safety1st]

ваши аргументы? »
Повнимательнее надо было читать тему. Предлагаю наоборот: Ваши аргументы в пользу NAT'а.

[exo]

Ваши аргументы в пользу NAT'а. »
мой реальный IP 95.143.214.140 - взломаете мой комп?
Повнимательнее надо было читать тему. »
я про аргументы 2-х нат. А вы не ответили на мой вопрос.
Я кстати сижу за двумя НАТ: один провайдера - второй мой WiFi роутер, я соседям (есть причины, почему они не подключают себе отдельно) раздаю интернет по WiFi.
Я не жалуюсь. Всё работает как часы :) + меня пользователи сети не "мучают".

и второй вопрос (так, чисто для себя): у вас одна сеть? DHCP используете только для раздачи адресов?

[Kiber]

1022 хоста, у вас реально столько машин? »
Судя по количеству админов, полагаю что здесь маска - не вопрос лимита, а вопрос удобства.
Тогда возможно у вас маршрутизатор и коммутаторы поддерживают VLAN ? Какие у вас модели? »
А при чем тут VLAN?
Для VLAN'а надо чтобы его поддерживали все сетевые устройства.
Это слишком трудозатратно. Результат себя не окупает.

Ваши аргументы в пользу NAT'а. »
Вы сравниваете вещи, которые в принципе сравнивать нельзя. Их использование исключительно зависит от ТЗ.
Это всё равно что сравнивать ручку с карандашом. Оба пишут, и вроде принцип одинаковый.
Но мы-то с вами значем, что они совсем разные.
Так и тут, нельзя построить сеть из одних NAT'ов. Это бессмысленно.
Как и нельзя построить всю сеть только на маршрутизации. Рано или поздно воткнёшь NAT.
Они эффективны только в совокупности.

Кстати, Изо, а зачем отменил полезность? Неужели разглядел бред?

[exo]

А при чем тут VLAN?
Для VLAN'а надо чтобы его поддерживали все сетевые устройства. »
ну вообще-то я и спросил автора, какие у него модели.
А при чём тут VLAN - да при том, что каждую сеть можно загнать в разные VLAN без маршрутизации между собой, и буду они раздельно жить.

[Safety1st]

мой реальный IP 95.143.214.140 - взломаете мой комп? »
Вы это к чему?

я про аргументы 2-х нат. А вы не ответили на мой вопрос. »
Я ответил, но вопросом на вопрос :) Мне проще объяснить свою позицию от противного. Что такого даёт 2-й NAT в частной сети, что не может дать маршрутизация? Пример, который Вы привели, из другой оперы: сеть провайдера не в Вашем подчинении, Вы не можете вводить в неё хосты. Здесь NAT - единственная возможность. И причина - в необходимости. Аргумент 'компы надёжно защищены NAT'ом и недоступны извне' я не рассматриваю: это простой способ защитить сеть извне (хорошо подходит для домашних юзеров, непосредственно подключенных к Интернет), а у нас 2 дружественные сети и есть специалисты для настройки. Какие ещё причины могут быть за 2-й NAT?

у вас одна сеть? DHCP используете только для раздачи адресов?»
Я, наверное, ещё пожалею, но отвечу :) Я работаю только в SOHO, поэтому везде сети одни. По DHCP раздаю то, что нужно. Обычно это параметры 3, 6, 15, 46 для IPv4 и 23,24 для IPv6.


Kiber, очень понравилось последнее сообщение. Особенно про ручку и карандаш :)

Как и нельзя построить всю сеть только на маршрутизации. Рано или поздно воткнёшь NAT.
Они эффективны только в совокупности. »
У меня несколько иная позиция: я рассматриваю NAT лишь как пристройку (расширение) над маршрутизацией, которую приходится иметь на границах с WAN. Мне очень интересно поподробнее узнать Вашу. Когда возникает необходимость 'втыкать NAT' (кроме приведённых мною случаев)? А когда 'NAT втыкают' не из необходимости? И что значит 'эффективны в совокупности'?

Для VLAN'а надо чтобы его поддерживали все сетевые устройства. »
Я думаю, можно обойтись только на некоторых. Ведь можно иметь нетэгированный VLAN в основных местах. Но из приведённых вариантов этот самый сложный и затратный. Из всех возможных способов лучше выбрать попроще (и подешевле), решающий поставленную задачу. Ваш вариант с адресами 172.16.0.0/16 мне больше нравится, чем VLAN, но для расшаривания только пары серверов я бы стал использовать всё-таки свой. Я ведь думал над другими адресами, но несколько иначе: IP 172.x.x.x назначается только серверам, клиентам обоих сетей по DHCP рассылается маршрут (192.168.x.x - через роутер, 10.x.x.x. - on-link) и, конечно, маршруты на роутерах. Но здесь возникнает ряд сложностей из-за того, что сервера становятся логически multihomed (простите, не могу вспомнить как это по-русски), т.е. имеют несколько IP-адресов. Не хочу сюда углубляться. При доступе по имени *.static.local могут возникнуть сложности из-за того, что на самом деле сервер имеет другое имя. И т.д. С группой фильтров непредвиденных сложностей нет: сформировать список фильтров, исключить на DHCP и загнать сервера в этот диапазон.

Кстати, Изо, а зачем отменил полезность? Неужели разглядел бред? »
Ну, что ж сразу бред? Вы поначалу первую половину написали. Она вызвала желание поставить полезность. Добавили вторую половину. Она достаточно сумбурна :), со многим не согласен (всё про юзеров (доступ нужен всем), неоднозначность при обработке (сервер будет отвечать с того же IP по-любому), 'забавная схема' не кажется правильной организацией, 'можно не прописывать второй ip для сервера' - совсем не верно (сервер не будет принимать пакеты на тот IP, который ему не назначен)). А полезность стоит под всем сообщением. Я решил не оставлять полезность на том, где далеко не всё разумно.

без маршрутизации между собой, и будут они раздельно жить »
Нужно, чтобы они жили чуть-чуть вместе :)

[exo]

Пример, который Вы привели, из другой оперы: »
я согласен, что многое зависит от ситуации.
поместили за целыми 2-мя NAT, что является крайне нерекомендуемой конфигурацией, используемой только по незнанию. »
однако, мне непонятно вот это - по незнанию чего? незнанию НАТ или того что можно без него обойти в данном случае? как я поянл из последнего поста - имеется ввиду конкретно этот случай.
Нужно, чтобы они жили чуть-чуть вместе »
упустил, сорри. А вот если оборудование уже поддерживает VLAN - то это уже не затратно.
Я, наверное, ещё пожалею, но отвечу »
никогда ни о чём не жалейте, кроме того, чего не успели сделать. ваш пост очень даже информативный.

[Kiber]

Ну, начнем с того, что я считаю, что точность и простота - залог надежности.

Когда возникает необходимость 'втыкать NAT' (кроме приведённых мною случаев)?»
При необходимости поднять безопасность или использовать дополнительные адресные пространства без возможности или желания переписывать конфигурацию существующей сети. Ну вообще, случай 'втыкания' NAT на границе с WAN это и есть частный пример подобной необходимости.

А когда 'NAT втыкают' не из необходимости?»
По желанию? Извините, вопрос больше фиолософский. Чем ваше 'не из необходимости' отличается от 'необходимости'?

И что значит 'эффективны в совокупности'? »
Означает что они используются повсеместно, и представить себе глобальную сеть без первого или второго немыслимо.
Так и тут, нельзя построить сеть из одних NAT'ов. Это бессмысленно.
Как и нельзя построить всю сеть только на маршрутизации. Рано или поздно воткнёшь NAT. »

Я ведь думал над другими адресами, но несколько иначе: IP 172.x.x.x назначается только серверам, клиентам обоих сетей по DHCP рассылается маршрут (192.168.x.x - через роутер, 10.x.x.x. - on-link) и, конечно, маршруты на роутерах. »
Решение задачи в большей степени зависит от постановки. В данном случае нам нехватает данных по обеим сетям. Что это за сети? Для чего используются? Какие перечислимые виды отношений и ресурсов внутри сети? Как в будующем может потребоваться связать их?
Насколько я понял, 10.0.0 - сеть с полными правами, 192.168.1 - сеть только для интернета, плюс ограниченный набор пользователей должен иметь доступ к ресурсам 10 сети.
В таком случае легче всего воткнуть в шлюз сети 192.168 еще одну сетевушку. Выдать ей 172.16.1.1/24, линк воткнуть в оборудование 192.168.1. Перевести нужных пользователей из 192.168.1 в 172.16.1. Затем прописать фильтры для каждого пользователя с маской 32 из 172.16.1 в 10.0.0 и обратно. И фильтр между 192.168 и 172.16.1.
Если не планируете понижать маску сети 192.168.1, то можно вместо 172.16.1 использовать 192.168.128 (например).

При доступе по имени *.static.local могут возникнуть сложности из-за того, что на самом деле сервер имеет другое имя. И т.д.»
Не соглашусь. Без разницы, какое имя имеет сервер. Если вы про доступ к виндовым шарам, то насколько я знаю, токен безопасности основывается на имени, по которому ты обращаешься, а не под которым себя видит сервер. А глубже всё резолвится в ip, а транспорт к имени не имеет никакого отношения.

С группой фильтров непредвиденных сложностей нет: сформировать список фильтров, исключить на DHCP и загнать сервера в этот диапазон. »
Вообще никогда не понимал каким образом DHCP, сервис, который по сути не гарантирует защищенность адресных пространств, может использоваться для безопасноти.
Допустим, падает DHCP. Сыпятся звонки - ничего не работает. И тут уж либо исправлять в кратчайшие сроки, либо каждого перенастраивать вручную. Это, кстати, один из минусов использования DNS. Хотя, на моей памяти, ни один нормально настроенный DNS не падал.

Ну, что ж сразу бред? ... А полезность стоит под всем сообщением. Я решил не оставлять полезность на том, где далеко не всё разумно. »
Да, я так и подумал. Revoke'нул плюс - готовь approve! :D

всё про юзеров (доступ нужен всем)»
Не понял.

неоднозначность при обработке (сервер будет отвечать с того же IP по-любому)»
Подразумевалась обработка пакета от пользователя фильтрами на маршрутизаторе. У пользователя 2 IP на одном интерфейсе. Адрес отправителя в данном случае вещь неоднозначная.

'забавная схема' не кажется правильной организацией»
Это лишь пример того, как _может_ работать сеть, а не того, как _надо_, остаточный эффект миграции. Надеюсь, это было очевидным. Предположим, есть Сервер и Админ (не я). Админ написал Прогу для своей БД. Прога используется _КЛИЕНТАМИ_ для доступа к этой БД. В Прогу зашит IP Сервера. Админ очень дорожит своими _КЛИЕНТАМИ_ и не хочет ни на секунду отрывать их от работы (или себя, тут уж непонятно - такой Админ). Как вы понимаете, дальнейший мув только за Админом, и чувствую, что скоро ему будет поставлен deadline, после которого Серверу будет удален старый ip.
Собственно, сам пример весьма рабочий, если вы, например, имели дело со спутником.
Покажите, где написано, что трассы от клиента до сервера и от сервера до клиента должны быть симметричны.

'можно не прописывать второй ip для сервера' - совсем не верно (сервер не будет принимать пакеты на тот IP, который ему не назначен)).»
Вы совсем неправильно поняли предложенные схемы.

[exo]

Допустим, падает DHCP. Сыпятся звонки - ничего не работает. »
решается арендой на 8 часов как минимум. Упал DHCP, для тех кто уже работает - ничего не изменится. А вот новые (опаздывавшие на работу) не смогут работать.