Сергей

Прошу простить остальных отвечавших, то решение, которое выбрал, очень функциональное и удобное. Самый лучший вариант НА МОЙ ВКУС из всех предложенных. Ответившему - ушло спасибо в карму на хабре

Не совсем устраивает вариант, т.к. у нас большое количество пользователей с разделением обязаностей между ИТ-шниками по географическому принципу. Каждый рулит своим контейнером, у каждого свои политики и т.д. В вашем варианте, нам придется отслеживать, чтобы все правильно нагородили у себя политики. А планировалось просто отдавать папку с обновлениями. Самый оптимальный вариант - подкладывать серверу файлы, чтобы он их индексировал.

Они не "торчат" в интернет. Шлюз за PPPoE туннелем до провайдера, диапазон получаемых адресов динамический. Сами компы за НАТом на фряхе, акцесс-листы и все такое. Если не поднимать VPN до компьютера по разрешенным портам, то в сеть снаружи не пробиться.

Про самоподписанные сертификаты я не говорю, их вообще не проблема нагенерировать. Я говорю именно про официальные, выданные доверенным центром. Стоят дорого, но серверное брэндовое оборудование, сетевое оборудование cisco, лицензионное ПО - все дорого стоит.

Сами говорите, что уже год костыль убираете и не можете убрать. Я сразу хочу красиво сделать, чтобы в будущем, при любым расширениях, не иметь проблем.

В будущем, я планирую раширить канал, уйти от провайдера, вынести в корневой домен COMPANYNAME.ru зону DMZ с почтовиком, файловым сервером, веб-сервером и т.д., а компы за файрволом будут в office.COMPANYNAME.ru. ИМХО нормально. Или есть еще подводные камни?

Я слабо представляю, как различный софт обрабатывает эту запись, но за идею спасибо. Я в эту сторону даже и не думал. COMPANYNAME.loc решил не делать, мало ли что будет в будущем? Захотим сертификат в будущем сделать, а он, насколько я помню, на левые домены не делается. Решил из "рекомендованного" диапазона имен сделать, остановился на методе office.COMPANYNAME.ru. А какие подводные камни могут в этом случае вылезти? Я навскидку пока проблем не придумал, а то может быть стоит еще что то переделать, пока компы в домен не повгонял?

Почему очень часто обсуждение технических вопросов переходит в хамство? А еще находится "самый умный начальник", который решает, кто и что должен делать. Я задавал вопрос: "как НАИБОЛЕЕ ПРАВИЛЬНО решить этот вопрос", а не "каких костылей можно нагородить, чтобы сегодня от меня отстали". Я сам навскидку придумал штук 5 решений из разряда "костылей". Просто хотелось узнать мнение знающего и более опытного специалиста, а не решение тяп-ляпкина, работающее с оговорками или в определенных рамках. Некоторые предложенные решения я не считаю костылями, но они не вписались в мои планы по расширению структуры сети. Но все равно очень интересно почитать рекомендации коллег.

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

Пара комментариев. Типовое решение - это не всегда правильное решение. Правильное решение, это когда админ забыл о способе решения или пришел другой админ и в случае любых проблем, корень ее находится за несколько минут. В некоторых организациях видел костыли, которые до поры до времени работают, но про которые все забыли или не знают. Потом поиск проблемы и ее устранение займут лишние часы.

По фен-шую серверов должно быть 2. Сейчас его нет, т.к. не предусматривали выделение финансов на него в этом году. На второй деньги заложены в бюджете следующего года. Надеюсь, существующий проживет несколько месяцев до получения второго. Придет второй сервер - добавлю одну строчку в настройках DHCP и все будет работать нормально. Где вы проблему увидели?

Вы писали

Работ системного администратора и заключается в том что заниматься подобным. А ваша формулировка делает из этого трагедию. Если запись не нужна, то ее тупо сносят. Заводят новую. И всё снова стает на рельсы. И это не является "сбоем" как вы пишите. Решение с www как раз и есть общеупотребительным.

Для любого вменяемого админа важна максимальная автономность системы. Постоянно вручную отслеживать, не изменился ли адрес у веб-сервера. Виртуальный сервер будет мигрировать на другое железо при превышении порога нагрузки на железе, при выходе из строя комплектующих, а я буду отслеживать и переписывать записи в ДНС? Для этого есть ДНС сервера хостера, где хранится самая актуальная информация. А на них указывает как раз тот самый сервер 8.8.8.8, который у меня указан вторым или третьим по списку.

Почему меня не устроил костыль в виде записи www.companyname.ru в AD компании? Могу пояснить. На веб-сервере могут быть кнопки или ссылки, указывающие на имя "companyname.ru". Оператор, занимающийся обновлением информации на сайте, нажмет на такую ссылку и опять будет звонить мне, чтобы я разобрался, почему сайт не работает. Чтобы этого не случалось, надо отслеживать содержимое сайта. Завтра захотим поменять движок или прикрутить какой-нибудь плагин и опять отслеживать их исходники? Я могу забыть или сменить место работы, а в случае чего мозг вынесут мне. Зачем держать такой костыль, который будет работать только в определенных условиях и про который всегда надо помнить?

Прокси на 80-м порту контроллера тоже не рассматриваю. Серверов не так много, мало ли, захочу вывесить на цеб-страницу обновляемый из AD телефонный справочник или другую лабуду.

Спасибо всем. Я прочитал кучу информации по костылям, изобретаемым народом, но красивого решения проблемы не нашел. Решил потерять несколько часов работы, грохнул домен COMPANYNAME.ru и создал office.COMPANYNAME.ru. Пока далеко все не зашло, решил сразу сделать нормально, чтобы через годы не вылезли разные неисправимые проблемы.

Когда несколько контроллеров домена, то при пинге ИМЕНИ ДОМЕНА отвечает случайный контроллер. Если же он один в домене, то он и отзывается.