Как организовать выход в интернет в доменной инфраструктуре на Windows Server?
Добрый день!
Подскажите пожалуйста, для небольшого офиса планируется структура серверов на гипервизоре esxi, на нём
1. Windows Server AD DNS DHCP 10.10.10.1
2. Windows Server ROUTING, NAT 10.10.10.2
На втором сервере где роль nat, анонсировано 2 ethernet порта, один во внутреннюю сеть, второй WAN, интернет сервер видит без проблем.
В настройках dhcp распространяю выдачу ip адресов, указываю dns домен-контроллера (*.10.1) и основной шлюз (*.10.2)
Интернет у пользователей не работает, так как нет разрешения внешних узлов.
Вопрос в чём
1. Не хочется сервер DC выпускать в интернет, чтобы все роли поднять на нём, поэтому шлюз в интерфейсе и DNS не указаны
2. Как реализовать при пересыл DNS запросов внутри сети для разрешения внешних имён на клиентских ПК?
(попытался поднять на 2-м сервере dns с пересылом на 8.8.8.8) а на DC в DNS пересыл на *.10.2, работает очень медленно, пинги идут но сайты или вообще не открываются или оооочень медленно) и мне схема такая не нравится.
3. Чем ограничивать доступ к интернету, в ad заведена группа internet, туда включены пользователи кому можно выходить, но чем этот механизм реализовать, чтобы ПК и сервера без учётной записи с доступом не выходили в сеть?
В настройках dhcp распространяю выдачу ip адресов, указываю dns домен-контроллера (*.10.1) и основной шлюз (*.10.2)
Так делать нельзя: клиенты по Windows в каждый момент работают с одним сервером DNS (по крайней мере - при елинственном подключении сети), на другой они переключаются при недоступности первого.
Настраивайте в качестве сервера DNS для клиентов только КД (точнее, сервера DNS на нем), а для самого КД обеспечьте возможность разрешения имен в общемировом DNS. Если не хотите разрещать ему доступ к любым серверам DNS в интернете (кстати, почему?), используйте DNS-сервер или DNS-прокси на шлюзе: настройте его как сервер пересылки в консоли сервера DNS в Windows.
Для п.3 вам требуется прокси-сервер. Какой - не посоветую: что там сейчас на какой платформе модно (и вообще поддерживается) - я не в курсе.
Я видимо не верно выразился, имел введу основной шлюз указываю ip второго сервера который имеет доступ к wan, а ip dns указываю домен-контроллера.
Как я уже написал в посте, попытался завести второй dns сервер на стороне nat сервера для пересылки,
пинги и разрешение имён работают нормально, а сайты открываются очень долго и тормозит загрузка.
На дк я бы разрешил dns'у доступ, но как без разрешения выхода в интернет это сделать?) причина - безопасность, не хотелось бы петю получить на DC..
Обычно NAT и маршрутизацию на винде не делают. Маршрутизацией и защитой от какеров обычно занимается микротик, который ставится по фронту, а контролем доступа - прокси, которое подымается тут же на гипере. Можно на гипере поднять и шлюз, но это чревато падением гипера и необходимостью восстанавливать шлюз.
Можно по фронту поставить линух, который будет и роутером и файрволлом и прокси (и DNS разумеется, и NTP и еще чертом лысым), а на AD настроить форвардинг запросов DNS.
К сожалению из железа только неуправляемый коммутатор.. По поводу падения esxi - честно говоря ни разу не подводил данный гипервизор за последние лет 7-8, на некоторых серверах несколько лет без перезагрузки трудятся 6.5 и 7.0
Да по линуксу я уже думал, НО - не могу понять практическую разницу, что на виндовом сервере поднимать это хозяйство, что на убунте или альте каком-нибудь..
По поводу DNS - вы по сути ту же схему предложили что я уже попробовал, ad dns форвардит в dns сервера где поднят nat, а там форвард на внешку..
5erdriver, Нет, я не про падение esxi - это штука достаточно бронебойная, если хорошее железо, она годами пашет. Я про падение виртуалки с роутером, если было пропадание питания. Линух тут еще более чем менее, а вот с FreeBSD - полный писец в этом отношении.
не могу понять практическую разницу, что на виндовом сервере поднимать это хозяйство, что на убунте или альте каком-нибудь..
Винда не предназначена для работы с сетями - это игровая система. Ее ниша - игрушка-кинушка-порнушка, вот тут она фору даст всем. А с сетями работать у нее тяжко.
По поводу DNS - немного не так.
AD форвардит запрос на DNS на линухе/микротике (который глядит во внешку), который этот запрос обслуживает. Поставить кэширующий сервер - пара пустяков, можно форвардером прописать сервера прова. Или сервера гугла, да хоть черта лысого.
CityCat4, в большой корпорации работаю, цепочка dhcp/dns серверов построена на виндовых серверах,
но физическая маршрутизация конечно на базе управляемых коммутаторов.
Так хорошо, а если на каком-нибудь altlinux или ubuntu стартануть такой маршрутизатор, какой софт лучше использовать для поднятия данной задачи, ещё чтобы из AD контролировал выпуск пользователей в wan?
Винда не предназначена для работы с сетями - это игровая система. Ее ниша - игрушка-кинушка-порнушка, вот тут она фору даст всем. А с сетями работать у нее тяжко.
CityCat4, хватит распространять тут мракобесие. Windows (и уж Windows Server - всяко) - это универсальная платформа для запуска приложений. И с сетями я с ней много работал, ничего особо тяжкого не заметил. Но уметь в сети при этом таки надо, да.
Другой вопрос - целесоообразность использования именно Windows для данной задачи - таковую я не вижу. Дорого это: и железо требуется которое x64, и сама платформа денег стоит, (если услугами дистрибьютора Jolly Roger Inc не пользоваться, но этого дистриббютора почему-то отдел "К" не любит).
Можно на гипере поднять и шлюз, но это чревато падением гипера и необходимостью восстанавливать шлюз.
Почему это чревато - непонятно. Лично я в аналогичной ситуации (1 железка, требуется выделенный шлюз) поднимал в качестве шлюза виртуалку на основном сервере с ролью Hyper-V (КД и пр.) с TMG на ней (но TMG давно уже не с нами). Поверхность атаки на сам гипервизор в такой схеме минимальна: из его сетевого стека используется только виртуальный коммутатор.
Здесь тоже можно сделать аналогично, но в качестве прокси-сервера (автору согласно п.3 он требуется) использовать программу стороннего производителя. Какая ОС будет на виртуалке - вопрос совершенно сторонний. Новички часто предпочитают Windows Server из соображения что "это тоже Windows", типа, дополнительных знаний не нужно, но они заблуждаются: знания таки нужны.
PS А в качестве сервера DNS в сети с доменом AD обязательно (практически, теоретически-то возможны варианты) должен использоваться сам КД и только он. Иначе возможны всякие странные вещи. Форвардинг не обязателен: MS DNS Server отлично работает и через корневые серверы DNS. Имейте это в виду когда будете в следующий раз распространять заблуждения.
MVV, вопрос по железу у нас не стоит и по лицензии на winserver тоже, он уже как бы есть, вопрос в том как сконфигурировать правильно и безопасно, если есть возможность с КД пересылать запросы на WAN, я только за, не хочется плодить dns сервера. Есть некоторые знания и по linux, но на мой взгляд получается тоже самое только на другой платформе, зоопарк плодить тоже не очень бы хотелось, но если линукс действительно более производительно программно маршрутизирует сеть, то не против..
Прежде чем типо бросаться типо умными словами - неплохо было бы знать, что они означают, иначе можно немного встрять :)
мракобе́сие — враждебное отношение к просвещению, науке и прогрессу (Википедия). В буквальном смысле "помешательство на темноте".
То есть заявляя, что мое утверждение "винда - исключительно игровая система" есть мракобесие - Вы заявляете, что Windows есть символ посвещения, науки и прогресса?
Ну да, сильное заявление.
Почему это чревато - непонятно
Оттого, что вот лично Вы не сталкивались с данной ситуацией - вовсе не значит, что такой ситуации не бывает. С линухом правда так не было, но с FreeBSD - запросто.
Не, не помешательство. Слово для этого есть другое: "корчи". Ну да ладно. Я все равно в переносном смысле писал, если переписать буквально - хватит распространять невежественные заблуждения.
С линухом правда так не было, но с FreeBSD - запросто.
Irsi на вас нет ;-) Ну да ладно. Причем тут вообще FreeBSD, когда речь про Windows? Hyper-V подключать к недоверенной сети чисто как виртуальный коммутатор (т.е. не делать виртуальный интерфейс в этом коммутаторе для хоста) достаточно безопасно: коммутатор работает на канальном уровне, приложения на хосте к этой сети подключатся не могут, так что поверхность атаки минимальная.
PS А взлому все ОС и приложения на них подвержены. Я вот лично чистил от руткитов и Windows, и Linux. Но все это было давно (на Linux - когда SSH 1 сломали, на Windows - парой лет попозже).
Вы сами стреляете себе в ногу и удивляетесь, почему больно. Ваш днс сервер кроме ваших локальных имен ничего не знает, т.к. к внешним днс не имеет доступа. Дайте ему шлюз и днс и можете средствами брандмауэра разрешить ему только 53 порт udp наружу
Средний
Простой
Простой
Простой
