Good Practice по настройке небольшой локальной сети на базе Active Directory

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

В данной статье я постараюсь описать правильные, с моей точки зрения, решения по созданию инфраструктуры сети малого предприятия. И конечно, данная статья отражает личный good practice автора и может отличаться от идеалов читателя.

Итак. Мы имеем в активе до 100 клиентов. Все стандартно, пользователи ходят в интернет, шлют почту, пользуются файловыми хранилищами, работают в 1с, хотят более крутой компьютер и пытаются ловить вирусы. И да, облака мы пока не умеем.

Пара столпов практически любой инфраструктуры,

а далее мы с вами пробежимся по очевидным и не очень нюансам. Кстати, повторяю, у нас малый-средний бизнес, не усугубляйте.

Сохранность данных. «В серверную попал фугас».

Если к вам в серверную попал фугас, то вероятнее всего сохранность данных будет интересовать вас в последнюю очередь. Намного более вероятно, что 31 декабря трубу сверху прорвало, от этого там случился пожар и провалился пол.
— Данные — наше всё. Один из серверов резервного копирования должен находиться вне серверной. Это спасательный круг. Пусть даже на нем лежит только самое важное, за сутки-двое можно снова купить-арендовать сервера и развернуть рабочую инфраструктуру. Безвозвратно потерянную базу 1с вам не удастся восстановить уже никогда. Между прочим, старичок а-ля P4-2400/1024 с правильно организованными бекапами обычно справляется.

Мониторинг. «01.01.2013 02:24 | From: Zabbix | Subject: Nuclear launch detected!»

Вы прекрасно проводите время отмечая Новый Год в кругу друзей. Кстати, не только вы, сторож здания где вы арендуете помещения тоже времени зря не теряет. Таким образом, залитое водой сгоревшее помещение будет с утра приятным бонусом к вашей больной голове в Счастливом Новом Году.
— Если что-то идет не так вы просто обязаны узнать об этом первым. Те же SMS-оповещения о критически событиях — это норма. Кстати, если с утра через 5 минут после прозвеневшего будильника вам не отписался сервер мониторинга, пора бить тревогу. Ведь сервер который следит за сервером мониторинга тоже ничего не написал. А вообще, ничего страшного, у вас есть сервер резервного копирования вне серверной, который все же написал вам, что потерял всех, но сам в строю.

План восстановления. «Спокойно, Казладоев, сядем усе!»

Это самый страшный Новый Год в вашей практике. Да, получив смс и оценив ситуацию, пожарных вызвали сразу, и приехали они почти за 5 минут, и потушили быстро. Вот только все равно одна часть серверной обгорела, вторая была залита пеной, а третья провалилась в итоге под пол.
— Вранье, конечно. Это не самый приятный, но и не самый страшный Новый Год. Да, вас ждет напряженная неделя, но благодаря четкому плану вы знаете с чего начинать и что делать. Рекомендую в плане disaster recovery расписывать все досконально подробно, включая консольные команды. Если потребуется восстановить какой-нибудь MySQL-сервер, настроенный три года назад, врят ли вы вспомните какой-то незначительный нюанс на который в итоге придется потратить пол дня. Кстати, все пойдет несколько не так как вы планировали, возможно даже совсем не так, будьте к этому готовы.

Теперь к основам сети на AD.

Я не собираюсь расписывать преимущества кластеризации и прочих LiveMigration. У нас малое предприятие и денег на vMotion-ы нет. Врочем и не надо, большинство сервисов прекрасно резервируются «из коробки». Ниже не будет хау-ту по настройке, но я постараюсь дать верное направление для самоизучения.

  • Active Directory. Контроллера домена должно быть два, физически на разных железяках. Кстати, Microsoft не рекомендует (не рекомендовало) делать все КД в виртуальных машинах, т.е. хотя бы один КД должен быть чисто железным. В общем-то это ерунда, на разных физических хостах можно делать разные КД, только выполните общие рекомендации Майкрософт по настройке КД в виртуальной среде. Кстати, не забудьте хранить GC на обоих контроллерах домена.
  • DNS — это просто основа. Если у вас криво работает Служба Доменных Имен, вы будете постоянно огребать косяки на ровном месте. DNS-серверов должно быть минимум два и для этого нам вполне подойдут КД. И вопреки рекомендациям «Анализатора соответствиям рекомендациям» на самих КД я советую указывать мастером самого себя. И вот еще что, забудьте про практику прописывания серверов на клиентах по IP-адресам: если это NTP-сервер, то клиенты должны знать его как ntp.company.xyz, если это прокси, то что-то типа gate.company.xyz, ну в общем понятно. Кстати, это может быть один и тот же сервер с именмем srv0.domain.xyz, но с разными CNAME. При расширении или перемещении сервисов это очень поможет.
  • NTP-сервер, следующий за DNS. Ваши КД всегда должны отдавать точное время.
    Спасибо foxmuldercp за совет
  • DHCP-сервера должно быть тоже два. На этих же самых КД, вполне рабочая схема. Только настраивайте так, чтобы диапазоны выдачи не пересекались, но чтобы кажыдй DHCP мог покрыть весь парк машин. И да, пусть каждый DHCP-сервер выдает первым DNS-сервером тоже себя. Думаю, понятно, почему.
  • Файловый сервер. Тут тоже все легко. Делаем DFS с репликацией, на тех же КД. А вообще, репликация даже не при чем, просто всегда прописывайте ссылки на шары через DFS, старайтесь придерживаться этой практики по отношению ко всем файловым ресурсам. Когда понадобится перенести шару в новое место, просто переносите шару и меняете ссылку в DFS. Клиент, может, вообще ничего и не заметит.
  • MSSQL-сервер 1с. Это уже не просто. И дорого. У вас отчасти большая база, а держать резервный SQL-сервер непозволительно. Эту штуку отрезервировать не получится, в любом случае нужен новый инстанс, который стоит денег. Бекапы — наше все, ничего страшного. Продумайте где вы сможете по-быстрому развернуть временный сервер СУБД. Кстати, есть бесплатный MSSQL Express с ограничением на размер базы, может быть вам его хватит перебиться.
  • Шлюз. Linux и прочие FreeBSD. Как бы не было неприятно, но на TMG и прочие керио денег нет. Все равно придется разбираться в iptables. Тут могу дать однозначный совет — дружишь с OSI — проблем не будет, не дружишь — проблемы будут и с керио. Кстати, если вы считаете, что вы админ и не знаете, в чем разница между фреймом и кадром, то вам будет тяжело.
  • Безопасность. Очень обширная тема, поэтому следующие пункты про этот интимный вопрос.
    Юзеры должны работать под Пользователями домена. Любое, подчеркиваю, любое приложение можно настроить для работы в среде с ограниченными правами. Иногда достаточно добавить права на запись в каталог с установленной программой и внутри запретить запись исполняемых файлов. Иногда для выяснения особенностей потребуется мониторить реестр и файловую систему. Иногда захочется забить и выдать админские права. Иногда это целесообразно. Выбирать вам, но не отключайте UAC никогда. Да и вы, сидя за рабочим местом, максимум должны обладать правами локального админа над всеми рабочими станциями, ни в коем случе не админ домена. При необходимости рулите серверами через терминал.
  • Учетные записи. Про пользователей я промолчу, думаю понятно, что один аккаунт на одного юзера. Но не все понимают, что под каждый сервис должна быть своя учетная запись. К примеру, MSSQL, работающему в среде AD нафиг не нужны права админа домена. Создайте обычный пользовательский аккаунт и при установке СУБД укажите его. Инсталлятор сам пропишет нужные права и все будет прекрасно работать. И так почти с любыми сервисами. Если какой-нибудь openfire для подключения к AD просит указать admin account — это одно название, ему нужно всего лишь читать службу каталогов.
  • Обновление ПО. Разверните WSUS и не забывайте хотя-бы по вторым средам месяца заходить и проверять наличие новых обновлений. Выделите 10-15 машин из вашего парка и включите в тестовую группу. Новые обновления проверяйте именно на этой группе, а когда не обнаружите косяков, разворачивайте всем. Кстати, вот тут есть инфа как обновлять любой софт через WSUS.
  • Антивирус. Должен работать, а вы должны его контролировать. Про мониторинг я писал в начале.
  • СКС. Очень больная тема для многих учреждений. Тут совет только один. Если делаете сами, то делайте как для себя, в любом другом случае докажите руководству, что вашей компании жизненно необходимо предоставить работы на аутсорс. Помните, следующий админ может легко найти ваше место жительства.

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

Комментарии 80

    +2
    Вы не обижайтесь только, но с моей точки зрения, вам бы больше читать книг, а не заниматься выдумками. Это вообщем-то и отличает профессионала от дилетанта.
    Гугл в помощь по теме microsoft best practice active directory design. По остальным продуктам\решениям вы найдете в гугле не менее доходчивую документацию(и ваши best practice) от производителей ПО или мировых ай-ти гигантов.
    Удачи в вашем профессиональном росте!
      0
      Я пишу по своему опыту и на здоровую критику не обижаюсь. Наоборот, разнесите меня, желательно по пунктам. Я себя считаю профессионалом, отнюдь, не дилетантом.
      +2
      Томас Лимончелли, Кристина Хоган, Страта Чейлап «Системное и сетевое администрирование. Практическое руководство» www.ozon.ru/context/detail/id/4839442/
        0
        Это да, это всем и каждому читать :) Лежит прямо передо мной, перечитываю разные части время от времени — новые мысли приходят раз за разом.
        –1
        «Шлюз. Linux и прочие FreeBSD. Как бы не было неприятно...» Вы против *nix? Что в нем плохого?! По мне *nix админить на много приятнее. У меня почти весь парк серверов на FreeBSD и Linux (за исключением терминалки и 3х AD контроллеров). Начиная от маршрутизатора и заканчивая серверами виртуализации. Работает просто отлично и лишний раз к начальству ходить не надо — клянчить деньги на ПО. К стати админю моленькую бюджетную сеть из 12 серверов и около 100 рабочих станций.
          +1
          В типичной мелкой компании типичный «админ» — слабокомпетентный студент, надрессировавшийся тыкать по кнопочкам в гуе. Упомянутый Kerio прост как кувалда. IPTABLES требует длительного вдумчивого изучения матчасти, как и примерно все поднимаемые на *NIX сервисы.
          Вы осилили бесплатные решения? Поздравляю. Но завтра вы увольняетесь, на ваше место приходит тот самый студент — и вскоре вся инфраструктура встает раком.
          Ну и не забываем, что мелкие конторы могут расти, и в какой-то момент окажется, что сопровождение опенсорса отнимает слишком много сил, а возможностей опенсорса уже не хватает.
            +2
            3 года назад я и был тем самым студентом 3-4 курса, стыдно сказать не знал что информация в сети передается пакетами и что такое сетевая маска. То куда я пришел было просто ужас, справедливо заметить мои знания тогда тоже были ужасны. Не было ни чего. Только куча проводов которые неизвестно куда идут, терминалка, DC с win NT, комп с WinXP на котором стояло: MDaemon, traffic inspector, несколько ИПС, MySQL, Apache, PHP и еще кое что, он же смотрел линком в инет. И все это добро стояло в кабинете начальника. А сейчас там новая СКС с подробной схемой, оптические линии между зданиями, новая серверная, распределительные устройства в на каждом этаже + 1 главное на здание, разделение рабочих групп на VLANы, карты VLANов IP сетей и ACL, демилитаризованная зона, 2 канала в инет c балансировкой, несколько серверов для виртуализации, основной и резервный файловый сервер, естественно есть AD (3 контроллера, 1 на физическом железе и 2 в xen), внешний и внутренний mail сервера, мониторинг узлов, удаленный доступ в сеть, и еще кое что для обеспечения информационной безопасности. И почти все крутиться на FreeBSD и Linux. А внешние службы http, mail, dns крутятся на VPS хостинге. Так что вполне реально все это осилить. К стати на всем предприятии и его филиалах я единственный it специалист. И помимо администрирования у меня еще есть обязанности. Со всем справляюсь и даже остается время на само образование и создание своих небольших проектов. Одна беда — когда уезжаю в отпуск приходиться писать подробный мануал для начальника.
            P.S. Я не пиарюсь. И ни в коем случае не считаю что лучше других. Но считаю что каждый должен стремиться к совершенствованию своих знаний и навыков.
              +2
              Но считаю что каждый должен стремиться к совершенствованию своих знаний и навыков.

              Вот допустим вам захочется хорошую работу с приличным окладом. «На всем предприятии и его филиалах я единственный it специалист» — это ведь кошмар. Вы увольняетесь, и всем этим зоопарком начинает управлять новый студент — а вы рвете с фирмой все контакты. Опишите, что произойдет с ней после этого.

              Я всегда говорил «если делаешь что-то, то делай это хорошо». Но иногда бывает перебор, и «слишком много хорошо» становится недостатком. Зачем усложнять на ровном месте? К примеру, зачем бить сеть на VLANы (помимо сервера-DMZ-юзеры-голос), если во всей компании всего сто сотрудников? Зачем делать ACLы между VLANами? Если мы говорим о пользовательских VLANах, то такое не принято делать даже в компаниях с десятками тысяч сотрудников в целом и тысячей сотрудников в этом конкретном здании так не делают. Да и весь ваш серверный зоопарк неизбежно содержит столько самописных костылей, что новому человеку потребуются месяца для осмысления всего этого.

              Хорошо спроектированная инфраструктура — не только та, которая работает хорошо, но и та, которую легко сопровождать. Это, кстати, одна из главных причин, по которым очень крупные компании, не владеющие мощным штатом собственных разработчиков, шарахаются от опенсорса как от чумы. Тратя десятки миллионов долларов в год на лицензии к абсолютно проприетарному софту. Это оказывается дешевле, чем опенсорс.
                0
                Усложнений на ровном месте не так уж и много. А про ACL и VLAN скажу вот что. До меня был прецедент. Сотрудник приходил со своим ноутом и занимался спуффингом. В результате были перехвачены задания отправленные на принтеры, деловая переписка начальства и что то еще.
                Теперь про то если придет другой. Я стараюсь документировать то что делаю. Для каждого сервера заведен журнал. В котором я описываю все что настраиваю или изменяю. Для СКС есть схема. По которой видно что где и куда подключено. Для ip, vlan и acl есть карта.
                А про простоту настройки вот что. Те же самые компании покупают cisco и настраивают ее через консоль. И тратят такие же миллионы не только на покупку, но и на обучение сотрудников. Причем бучение не разовое а регулярное. Им не приходит в голову купить dlink с web gui. Как Вы думаете почему? Может дело в надежности, гарантиях и сертификатах которые дает производитель?!
                А в моем случаи *nix это хороший компромисс между надежностью, ценой и функциональностью.
                  0
                  Сотрудник приходил со своим ноутом и занимался спуффингом.

                  Поставить коммутатор с поддержкой DHCP snooping, DAI и IP source guard. Плюс port-security. И хрен он чего наспуфит, он даже статический адрес себе задать не сможет. А разделение сети на VLANы разве что немного снизит область L2 атак, не более того.
                  По-моему, примерно все управляемые L2 коммутаторы поддерживают этот функционал.
                  А про простоту настройки вот что. Те же самые компании покупают cisco и настраивают ее через консоль. И тратят такие же миллионы не только на покупку, но и на обучение сотрудников. Причем бучение не разовое а регулярное.

                  В моей компании нет сетевого оборудования кроме цисок. Ну ладно, в некоторых блейдовых корзинах можно найти virtualconnect'ы, но я не признаю это барахло сетевым оборудованием. Да, стоит это много миллионов (долларов, не рублей). На обучение лично я ходил всего один раз за много лет (коллеги — плюс-минус столько же), да и там особой надобности в нем не было. Это обучение, кстати, копейки стоит. Ну на следующей неделе прогуляю работу и похожу на Cisco Expo, благо циска бесплатно приглашений подогнала, но и это не вполне обучение, скорее — реклама за деньги неблатных зрителей и возможность встретить старых друзей.
                  Вы вспомнили d-link'и. Почему не ставим? Потому что они тупо нефункциональны. Даже ентерпрайзные, не говоря уже о хомячковых. Нет в них нужных нам фич, а то железо, где они есть, стоит сравнимо с цисками. И это еще не говоря о надежности. С моей точки зрения, «опенсорс» в серверном ПО равен «дэлинк» в мире сетевого оборудования, т.е. сплошная иллюзия экономии и головная боль.

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

                      Но если некий инструмент изначально сложен в поддержке (а те же цискины железо/софт на самом деле в этом плане исключительно простые, именно этим и объясняется их популярность) — стоит трижды подумать прежде, чем разворачивать его. Особенно в условиях дефицита кадров, неизбежного для конторы из ста человек.
                      Вы все-таки не ответили: если через 2 недели вы увольняетесь, и на ваше место завтра нанимают нового человека, за те же деньги — что случится со всей инфраструктурой?
                      Документация есть, говорите? А она поможет? А она достаточно понятна для другого человека?
                      Сложные продукты заставляют вникать в детали, знать технические тонкости.

                      Никто не говорит, что в ваших условиях надо ставить сложные продукты. Они наоборот противопоказаны там. Однако, если есть задача «защититься от любых видов спуфинга», то и решение должно быть адекватным. Указанные мной выше технологии включаются одной командой или галочкой на каждую. Это просто к примеру.
                      Для не далеких людей это только затрудняет работу.

                      Вот я и говорю, что вы затрудняете работу человеку, который придет после вас. Скорее всего, после этого инфраструктура компании будет жестоко глючить несколько месяцев, пока в итоге не купят тот же керио.
                        0
                        Вы все-таки не ответили: если через 2 недели вы увольняетесь, и на ваше место завтра нанимают нового человека, за те же деньги — что случится со всей инфраструктурой?

                        Я вот наверное глупость спрошу, сильно не пинайте. Но если вы админ, а не начальник ИТ-отдела, то зачем вам заботится о том, что будет после вашего увольнения? Поддерживать и развивать инфраструктуру должно быть удобно именно вам и вашим коллегам. А новому админу будет деньги платить, что бы он разбирался.
                        Наверное по этому я использую очень много opensource решений.
                        Да, что бы ничего не забыть, документацию надо писать даже для себя. Это другой вопрос.
                          +1
                          зачем вам заботится о том, что будет после вашего увольнения?

                          Элементарная порядочность?
                          Ведь это очень похоже на тайм-бомбу.
                          Поддерживать и развивать инфраструктуру должно быть удобно именно вам и вашим коллегам.

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

                          Вспомните прекрасное утверждение — «пишите код так, будто поддерживать его будет склонный к насилию психопат, знающий, где вы живете».
                            0
                            Хотя бы потому что это непрофессионально и неэтично работать так, будто после вас хоть потом.
                              0
                              будто после вас хоть потом.

                              Шикарная фраза, запомню :)
                                0
                                Блин сначала не понял в чём прикол, фраза-то банальная, а потом увидел опечатку =)
                            0
                            То уйду я или нет с данного рабочего места напрямую зависит от компании. Если компания заинтересованна в работнике — он не уйдет. А если все же уйдет то от поведения компании напрямую зависит что станет с инфраструктурой. Например при хорошем раскладе я готов поддерживать (по возможности) инфраструктуру некоторое время и провести ликбез для нового сисадмина. Данный вариант уже к стати был оговорен с начальством.
                            К стати, могу привести следующий пример. Разговаривал я однажды с начальником IT отдела крупной фирмы. Даже не отдела, а дочерней фирмы которая специализируется именно на IT и оказывает IT услуги родительской фирме. Фирма достаточно известна, называть ее не буду. Там была такая проблема: ни как не могли отправить на пенсию специалиста который настраивал циски. Не могли найти замены. Нужен был инженер который бы хорошо разбирался в сетях и среди ночи мог бы поднять OSPF на циске. Да да именно среди ночи. Т.к. график работы был с дежурствами, и постоянными командировками, и отпуск летом не дадут, и еще много чего. Абсурд скажите Вы, разве трудно найти толкового сетивика, и будите правы. Но работодатель не хотел платить достойную з.п. и сам себя загнал в такое положение. Как решилась проблема не знаю. Я же от той вакансии отказался т.к. моя з.п. не многим ниже чем то что предлагали. А нагрузка на порядок выше. Быть вечером и в выходные с женой и детьми гораздо приятнее чем сидеть и караулить «кошек».
                              +2
                              То уйду я или нет с данного рабочего места напрямую зависит от компании.

                              Развиваться-то надо… Вам никогда не хотелось работать с серьезным железом и серьезным софтом — которые нецелесообразны в мелкой фирме?
                              Разговаривал я однажды с начальником IT отдела крупной фирмы.

                              Ну-ну. Наличие «IT отдела» уже говорить о том, что фирма — мелкая. Обычно бывает «департамент IT», «дирекция информационных технологий» и так далее, в которой работают десятки/сотни людей.
                              Работаем мы со многими крупнейшими интеграторами. С ними как правило подняты IPSec туннели. С одним из них наибольшие проблемы. Я, кажется, уже раза 4 за год помогал их сетевику настраивать и траблшутить туннель до нас. В виде «он мне присылает конфигурацию, а я говорю, что еще надо ввести, чтобы заработало».
                              ни как не могли отправить на пенсию специалиста который настраивал циски. Не могли найти замены.

                              Это говорит ровно об одном: за такие деньги ни один уважающий себя человек не хотел к ним идти.
                              И мне кажется, что ваша фирма едва ли сможет позволить себе человека, который грамотно сопровождал бы отстроенную вами инфраструктуру.
                              среди ночи мог бы поднять OSPF на циске.

                              Открою страшную тайну. «Поднять OSPF» — это элементарнее некуда. Недавно была статья «сети для самых маленьких», можете почитать, сколько команд для этого требуется. В принципе, того объема сведений про данный протокол более чем достаточно и для понимания того, как он работает, и даже для траблшутинга.
                              Любой сетевик обязан, будучи разбуженным посреди ночи, не поднять, а оттраблшутить, и не OSPF, а MPLS, либо общие проблемы с работоспособностью (например — «на ровном месте пошла в разнос»). Это уже интереснее будет.
                              И я, кстати, пару раз за все время действительно был разбужен дежурными из-за аварии. К сожалению, даже полностью резервированная сеть защищает лишь от полного падения железки, но вот защититься от ее расколбаса куда сложнее.
                              Быть вечером и в выходные с женой и детьми гораздо приятнее чем сидеть и караулить «кошек».

                              В нормальной компании вы проводите 9 часов в день на работе и остальное время — с женой и детьми. Иногда бывают организованы «дежурства» — это значит, что надо быть доступным по телефону, и в пределах получаса от компьютера с VPN.
                              Я ни разу в жизни не бывал в командировках (мой начальник бывал, но характер командировок был «оглядеться, что и как в новом крупном офисе, и пообщаться с местным руководством», сугубо добровольно). Я ни разу в жизни не ездил экстренно на работу во внерабочее время — любая проблема может быть решена удаленно. Иногда я выхожу на плановые ночные работы — это когда домой приезжает такси, отвозит на площадку, дожидается, отвозит обратно. Деньги — удвоенная почасовая, счетчик крутится от момента, когда вышел из дома, и до момента, когда вернулся домой. А на следующий день — отгул, неучитываемый в окладе, можно спать сколько влезет :)
                              Ну и «единственный сетевик в крупной компании» — бред. У моего прошлого работодателя было 15 сетевиков (замечу, это даже не провайдер, а банк, довольно крупный, но не самый). У текущего — поменьше, но полное многократное резервирование человеческих ресурсов имеется. Мы ходим в отпуск когда захотим, лишь бы не все сразу.
                              Еще знаю об одной компании, где сетевиков человек 20, причем они разбиты на смены, и ночная смена — вполне боевая. Ни у кого из сетевиков нет внешнего доступа к сети, и это достойно уважения.

                              Так что не ориентируйтесь на мелкие фирмы. В крупных все по-другому. И уж конечно не бывает бреда вроде «сетевик ездит по офисам», для этого есть техподдержка.
                                0
                                Мы с Вами разговариваем на разных языках и времени у меня осталось уже мало. Поэтому отвечу только на вопрос: «Развиваться-то надо… Вам никогда не хотелось работать с серьезным железом и серьезным софтом — которые нецелесообразны в мелкой фирме?»
                                Черт возьми, конечно хотелось, я готов и учиться и работать и нести ответственность за свою работу. Естественно за достойную з.п. и уважительное отношение.
                                От 2 до 5 часов рабочего времени каждый день я провожу за изучением стандартов, мануалов, статей и экспериментов со всей этой хренью. Однако хороших рабочих мест не так много в нашем городе и в ближайших городах. А те которые есть заняты своими людьми. Большинство вакансий у нас — это быдло инженеры. Сходи поставь винду, сходи объясни тетеньке как напечатать на принтере. Меня от этого в дрожь бросает, такое рабочее место для меня — страшный сон. Не говоря уже о частных мелких шарагах, которые работают на аут сорс. В такой я провел 2 дня. У меня волосы дыбом встали не то что на голове, но и в др местах. Сбежал от туда без оглядки.
                                Может показаться что я преувеличиваю. Однако мне периодически попадаются работодатели которые говорили примерно следующее: да видно что ты толковый парень, но мест нет. И что обидно это то, что говорят это именно в тех местах где бы я хотел работать.
                                  0
                                  В наше время есть острая недостача специалистов во многих местах страны и мира, а препятствий к перемещению всё меньше и меньше. Посмотрите вакансии в других городах/странах, отправьте резюме, презентуйте себя как отличного специалиста и будут вам задачи и достойная зп в три-пять тысяч долларов.
                          0
                          ACL между VLAN вполне себе могут быть полезны. Ну не обязательно L3 ACL, пусть хоть что — VACL, PACL или любое средство изоляции пользователей друг от друга, просто ACL гибче. В 2009, когда кидо зверствовал, в сети, в целом плохо обустроенной (плохо с обновлениями, антивирусной защитой и прочее, нет никаких секьюрити-агентов и серверов политик) но с изоляцией сетевой именно средствами телекома эпидемии практически не было. Не в пример соседним сегментам большой корпоративной географически размазанной сети.
                            0
                            VACL — как бы ACL, действующий в пределах VLANа, и потому тем более проще держать всех в одном VLANе :)
                              0
                              Я знаю что в пределе, на то они и V… Они не на всех моделях логирование умеют, а хочется еще кроме изоляции и потуги людей или злокода видеть. И опять же — все оборудование должно поддерживать. В условиях, когда частично умеет, а частично это вообще не циска — группировка юзеров по влан-ам и л3 ацл — вариант. Не слишком это обременяет и усложняет.
                              Хотя да, будь везде на доступе хотя бы 2960 — я бы подумал про упрощение до 2-3 влан-ов.
                                0
                                «все оборудование должно поддерживать» — ура унификации и стандартизации.
                                Практически любые L2 свитчи (управляемые) умеют применять VACLы.
                                Ну а на самом деле подобный подход (на коммутаторах ограничивать доступ) — зло. Должно быть как? IPS обнаружил заражение машины по характерным пакетам — порт подключения машины переходит в admin down, и администратору отправляется алерт. А то можно замучиться блокировать все хоть немного уязвимые порты. А если юзер захочет зайти на шару соседа? В мелкой организации это наверняка актуально.
                                И ведь есть и бесплатные IPS (snort?). И наверняка им можно допилить доступ на сетевое железо.
                                  0
                                  «И ведь есть и бесплатные IPS (snort?). И наверняка им можно допилить доступ на сетевое железо.»

                                  А вот это уже выпиливание лобзиком, сами же не любите :) VACL-ы многих не-цисок — полный кошмар и уж лучше обойтись без них. Шары у соседа — вопрос спорный, у себя это изжил. С портами не парюсь, зачем, когда бьешь по «площадям», правила получаются достаточно общие и при этом жесткие, тем более что TCAM не резиновая.
                    0
                    IPTABLES требует длительного вдумчивого изучения матчасти, как и примерно все поднимаемые на *NIX сервисы.

                    ГУИ давно перестали быть исключительно платными и виндовыми. Веб-интерфейс прикрутили почти ко всему, что только можно как под linux так и под freebsd. Тот же pfsense в качестве роутера.
                      0
                      Неистово плюсую pfsense, в базовом варианте (только доступ интернет и немножко NAT внутрь) спокойно админится даже человеком плохо понимающим все сетевые премудрости.
                        0
                        Речь даже не про гуй, а про… стандартизацию что ли. Предоставление администратору достаточных (простых и удобных) средств для выполнения всех нужных ему задач и одновременно мягкий (или жесткий) запрет на любые совсем нестандартные действия.
                        Да, вебинтерфейсы можно прикрутить к чему угодно. Ну что же — штатный гуй астериска к примеру просто невыносим (на мой вкус). Его конфиги — тем более. Pfsense не ставил, не знаю, но я сильно сомневаюсь, что он удобнее и безотказнее в работе, чем любой из продуктов того же Kerio. Ну а главное — в нормальном коммерческом ПО заранее известно, где что будет настроено. Можно за несколько минут осознать, что, как и зачем сделал предшественник. Про опенсорс такого сказать не могу.
                      0
                      Я за никс. У меня тоже на винде только клиенты и КД. И я не фанат чего-либо, я против, извиняюсь, гомосятины в сетях.
                      0
                      Вы забыли про NTP сервера, которые для домена критичны — разница в 5 минут по умолчанию — авторизации и утентификации конец. в домен Вас не пустят — их тоже должно быть несколько и хотя бы один на железке без виртуализации — как раз недавно с этим столкнулся, когда у меня на 8 часов мгновенно ночью улетели часы на всем чём только можно — циски, esxi, и когда меня Cisco ACS перестал пускать на железки т.к. разница с КД была те самые 8 часов я провозился около часа пока не увидел, где косяк.

                      Далее — у DFS могут быть проблемы если файлошары с репликацией — под терабайт — мне об этом даже MVP говорили, возможно в 12 сервере что-то и исправили.

                      бекапы — есть полезная штука как предыдущие версии файлов в 2008 и 2012 сервере — помогает не восстанавливать терабайтный бекап с ленточки несколько суток, если нужно восстановить файл на вчера.

                      А систему мониторинга windows серверов я собираюсь писать в рамках изучения C# ни нагиос ни заббикс с виндой толком не работают.

                      Вообще спасает тотальное минимум дублирование всех систем, лучше всего еще и геораспределённое.
                        0
                        Сейчас же допишу в статью про NTP.

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

                        Бекапы. да нет у нас лент и прочих стримеров тоже нет. Не усугубляйте, прошу вас.

                        Мониторинг. Охота изобретать велосипеды? В рамках изучения — ради бога.

                        Дублирование. Ну я и попытался описать как можно дублировать сервисы.
                          0
                          кстати антивирус обновляется по wsus шикарно и я про mse вообще забыл, что он есть. wsus проверяет обновления каждые два часа, каждые два часа же рабочие станию проверяются на сервере всуса и выгребают все обновления, не требующие ребута самостоятельно.
                            0
                            Честно — не знаю как обновляется антивирус через WSUS. Он и так прекрасно обновляется стандартными средствами. Но, за подсказку спасибо. Учту, если что.
                              0
                              Microsoft Essentials прекрасно обновляется через wsus как все современные продукты Microsoft.
                          0
                          Предыдущие версии файлов и в 2003 были.
                            0
                            Были, но я на 2003 не рисковал это использовать
                              0
                              Почему? Теневое копирование — штука весьма стабильная. И использовалась она не только для непосредственного восстановления предыдущих версий файлов (довольно непредсказуемого, т.е. это никогда не замена лентам, просто приятное дополнение при наличии лишних дисковых ресурсов), а и в качестве помощника для выдергивания из-под программ файлов, в которые прямо сейчас идет запись. Для того же бекапа например.
                          0
                          tmg не так уж и дорог, кстати
                            0
                            Как Вам сказать. не очень то и дорог, но почему-то я ни в одной конторе за весь свой стаж работы с 2003 года ни ису ни tmg не видел на просторах СНГ ниразу. в отличие от работающего как часы сквида, который на ура прикручивается к ad и доменной авторизации
                              0
                              Ну, во-первых, «не видел» не означает «не используется».

                              Во-вторых, вы, похоже, не полностью представляете, что такое TMG, раз сравниваете его только со сквидом: tmg далеко не просто прокси-сервер.
                              0
                              Да при чем тут TMG? Я думал будут прикапываться к фреймам и кадрам. TMG рулит, а у нас на лишний фотошоп денег нет…
                                0
                                tmg практически бесплатен.

                                я бы докопался только до использования DC в качестве файловых серверов
                                  0
                                  Докопайтесь. Почему нет?
                                    0
                                    Потому что на DC ничего окромя роли КД по хорошему быть не должно. только системные доменные шары.
                                    Все остальные роли должны быть вынесены на отдельные сервера, большую часть из которых можно запустить в core mode для снижения количества потребляемых ресурсов
                                      0
                                      ну я бы оставил на них dns и dhcp все же :-)
                                        0
                                        DHCP дело десятое, а без DNS и корректных NTP домен работать и не будет.
                                          0
                                          Я имею в виду, что если и вводить в своей сети dhcp-сервера, то лучше держать их рядом с dns, а значит и dc.

                                          Для корректности времени внутри членов домена никаких особых усилий прилагать не нужно, все работает из коробки.
                                          0
                                          Я бы тоже. Блин, щас ругаться начну. У нас малый бизнес. Нет у нас денег на приколюхи, приходится совмещать.
                                            0
                                            а виртуализация?
                                              0
                                              А еще под файловые сервера можно те же линукса с samba сервером использовать. как часы работает. и к домену на ура прикручивается.
                                                0
                                                мы уже поняли, что вы фанат линуксов )

                                                к сожалению, самба все же имеет некоторые недостатки, и вы о них наверняка ведь знаете ;-)
                                                  0
                                                  я? фанат линуксов? не.
                                                  я предпочитаю использовать подходящие инструменты для решения конкретной задачи — нужна бесплатная файлопомойка — хватит самбы, нужна файлопомойка с кучей политик — виндовая роль.
                                                0
                                                Это однозначно. По-моему, в статье вполне дан намек на виртуализацию. У меня вне вирт только хранилище, там нужна скорость.
                                                  0
                                                  падение скорости в виртуальной среде сейчас менее 1% )
                                                    0
                                                    Извиняюсь, И ЧО???
                                                    если в ESXi будет только один сервис, то зачем? Натив на дебиане будет быстрее.
                                                      0
                                                      Затем, что виртуалка всегда удобнее физической машины. Тут и легкость полного бекапа перед рисковой операцией, и полная отвязанность от железа, и простота клонирования с какими-либо целями, и хранение ОС в централизованной сторе, а не локально, и многое другое.
                                                        0
                                                        Поздний ответ лучше, чем ничего, у нас следующим образом:
                                                        Есть шустрое хранилище, под определенный формат данных, нет смысла разводить там гипервизор.
                                                        Бекап с хранилища через rsync, TTL — сутки. Потеря 50-100ГБ критична только в рамках суток.

                                                        Но я же писал, и повторюсь — не усугубляйте.До 100 клиентов, для десятка серверов писал советы.
                                                        0
                                                        затем, что всегда можно рядом поместить другие вирт машины, в случае дохлого железа проще и быстрее перенести на другое и т.п.
                                                  0
                                                  Для малого бизнеса есть SBS, например.
                                                0
                                                Не согласен. На ~100 клиентов не будет проблем.
                                                  0
                                                  На 300 тоже, но все равно плохая практика пускать пользователей на КД.
                                                    0
                                                    Почему? Я не понимаю.
                                                  0
                                                  А после некоторых лет практики Core mode можете сказать какой выигрыш в ресурсах?
                                                  0
                                                  мои best practices в том, чтобы по возможности максимально разделять в разных виртуальных машинах разные роли: контроллеры домена отдельно, файловые серверы отдельно, почтовый сервер отдельно, сервер 1с отдельно и т.д.
                                                    0
                                                    а так же их резервировать, регулярно обновлять и бекапить и проводить восстановление
                                                      0
                                                      Не советовал бы бэкапить и восстанавливать потом из бэкапа контроллеры домена. И MS не советует.

                                                      Необходимо бэкапить лишь базу NTDS.

                                              0
                                              И снимается с продажи с 1 декабря ;)
                                                0
                                                ничего себе, что это они? Ничего же вроде на смену не выпустили
                                              0
                                              Кстати, Microsoft не рекомендует (не рекомендовало) делать все КД в виртуальных машинах, т.е. хотя бы один КД должен быть чисто железным. В общем-то это ерунда, на разных физических хостах можно делать разные КД


                                              Это не ерунда. Например, как-то раз все «бесплатные» лицензии на VMware ESXi взяли и закончились.
                                                0
                                                Ну ведь частность же. Если очень страшно, то гипервизоры можно разные.
                                                  0
                                                  Любое ЧП — частность. Рассчитывать на общность «всё работает и будет работать всегда» много ума не надо.
                                                    0
                                                    На это никто и не рассчитывает. Наоборот, я рекомендую дублировать все сервисы.
                                                +1
                                                Кстати, если вы считаете, что вы админ и не знаете, в чем разница между фреймом и кадром, то вам будет тяжело.

                                                Простите, а в чем разница?
                                                Всегда считал что это одно и тоже понятие ( только с переводом или без) — PDU канального уровеня…
                                                Не считаю себя гуру администрирования, но стало интересно.
                                                  0
                                                  Я изначально решил, что автор оговорился, и на самом деле имелось в виду «пакет и фрейм», и решил не придираться к мелочам :)
                                                  Или может, это — вопрос с подвохом? Такое бывает очень забавно задавать на собеседовании. Грамотный человек скажет «разница в названии», неграмотный начнет нести ересь.
                                                    0
                                                    Я не оговорился, с подвохом :) В контексте канального уровня разницы нет.
                                                      0
                                                      Тогда расскажите, в чем же подвох?
                                                        0
                                                        Так в этом и подвох, что разницы нет.
                                                  0
                                                  Как-то сетевая инфраструктура осталась за бортом совсем (не СКС).
                                                  Контроллеров два, а подключены они куды, к одному ядру? Отказоустойчивость сетевого уровня при относительно бюджетных свичах не так уже сложна и дорога, зато крайне полезна.
                                                    0
                                                    Не могу не согласиться, лично мы работаем над этим.

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое