[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, для тех кто уже работает - ничего не изменится. А вот новые (опаздывавшие на работу) не смогут работать.