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

Имеем:
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 сейчас вся выключена.

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

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

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, переключатель оставляем на "Принимать все пакеты, кроме ...".

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

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

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

Начните с NAT.

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

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

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

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

Эх, все не как у людей. Добрался до щлюза. Отрубил нат, настроил фильтр, маршрут прописали они по моей просьбе на 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.

Это неконкретная формулировка без специальной сисадминской терминологии. Что значит 'видеть' в данном контексте? Видеть в списке сетевого окружения? :) Вы сами в начале писали: "Выходит, 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. Они т.о. не правы.

Ура! Вы теперь уже не говорите 'встроенный фаер' :) У 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-трафик. Это не так жёстко, но может быть достаточно. Какие-то порты перечислены здесь. Главное, что тогда более гибко можно фильтры настраивать. Нас уже не ограничивают правила RRAS.

Именно.
За ваш совет спасибо. Все получилось. Почерпнул многое для себя. Оговорюсь еще раз - от адмнистрирования windows отошел года 4 назад все напрочь забыл занимаясь freebsd. Учусь заново, вспоминаю.
Кстати о TMG, а она разве не только под x64? Ибо сервер щел из коробки с x32.

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

Извращенцы :) Вы бы еще 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. Извиняюсь за сумбурность. Понравившийся вариант можем разобрать подробнее.

Цитата:

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

ваши аргументы?

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

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

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

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

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

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

Вы это к чему?

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

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


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

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

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

Нужно, чтобы они жили чуть-чуть вместе :)

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

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

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

Означает что они используются повсеместно, и представить себе глобальную сеть без первого или второго немыслимо.
Решение задачи в большей степени зависит от постановки. В данном случае нам нехватает данных по обеим сетям. Что это за сети? Для чего используются? Какие перечислимые виды отношений и ресурсов внутри сети? Как в будующем может потребоваться связать их?
Насколько я понял, 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 (например).

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

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

Да, я так и подумал. Revoke'нул плюс - готовь approve! :D

Не понял.

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

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

Вы совсем неправильно поняли предложенные схемы.

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

Это противоположные понятия :) NAT 'для безопасности' подходит под желание - желание поднять безопасность :) А необходимость - это когда по-другому работать не будет.

Итак, уже 4 причины 'за NAT':
1. сопряжение LAN и WAN (частных IP с публичными)
2. невозможность изменить конфигурации присоединённых сетей, чтобы работало без NAT
3. отсутствие свободного адресного пространства
4. защита от незапрашиваемого изнутри трафика (типа 'безопасность')

Ещё есть? Мы доберёмся до истины :)

Я про более скромные масштабы говорю, не дальше сети одного предприятия, весь Интернет для которой - сеть WAN.

Я принял 'по умолчанию' :), что не ограниченный набор юзеров, а все юзеры сети 192.168.1.0. Ниже 'всё про юзеров (доступ нужен всем)' это имел ввиду, т.е. вся ваша информация по переводу юзеров лишняя.
Но даже если бы набор был ограниченным, мне кажется лишней 2-я сетевая карта, раз физически она будет в той же самой сети, а несколько адресов можно назначить на один и тот же адаптер.

Без разницы, какое имя имеет сервер, главное, чтобы он его имел, а не просто на DNS A-запись была. Я вспомнил! :) Есть команда NETDOM COMPUTERNAME /Add:<new-alternate-DNS-name> . Основное имя - одно и может быть несколько дополнительных. Если сделать так, то сложностей при доступе по другим именам 'с виндовыми шарами' (ещё работа с протоколом Kerberos и доступ к сетевым приложениям, RPC и т.д.) быть не должно.

Да никак. Я про него говорю только потому, чтобы исключить из назначения или зарезервировать IP для серверов.


Какой интересный переход DHCP-DNS :) Всё может упасть. Это не минус DHCP, а вообще всего сущего :)

Точно однозначная для доступа внутри 172.16.x.x И должна быть однозначная, если у юзера только один маршрут по умолчанию 0.0.0.0/0 через 192.168.1.1. В обоих случаях благодаря source selection algorithm, по которому компы выбирают адрес для отправки не от балды, а по строгим правилам.

Это-то да. Со спутником только на приём по-другому никак. Я считаю пример не нерабочим, а 'неправильной организацией', которая используется для обхода проблемы. А Вы - молодец, что придумали. А почему не сделали, чтобы и к серверу напрямую шли?

В 10 заповедях реального сисадмина. Шучу :) Есть принцип 'не умножать количество сущностей без необходимости'. Пока Вы не объяснили, зачем это нужно, выглядело именно так.

Может быть не всё правильно понял. Объясните этот кусок другими словами.

Угу. Хорошая мысль! А ещё DHCP совсем быстро и просто поднять на другом сервере. Нужно использовать избыточность, чтобы обезопаситься от отказов.

Подарил мне пару минут счастья :))).

Второй ip мог потребоваться, если доступ из 10 сети к 192.168 также нужно ограничивать.
И чтобы не заморачиваться с масками - можно добавить IP нужному серверу и прописать для него маршрут.

По Вашему предложению у сервера уже 2 IP: 10.x.x.x и 172.16.x.x. И без них нельзя, так? О добавлении какого ещё IP идёт речь?

Ленивый я. Не хочу создавать 'времянки', которые потом еще потребуется удалять, только потому что кто то еще более ленивый чем я. Да и неправильно это - когда вся сеть уже перешла на новую адресацию, держать софт, который использует старую :).

Уже не идет. Речь прошла. Умерла родная.
P.S. И никогда не шла, кстати.