Доброго дня всем.

С момента выхода системы Wi-Fi доступа UniFi от Ubiquiti Networks (правильно произносится: «Юбиквити») прошло больше года.
Первая версия системы, описанная в нашем посте, совершила маленькую революцию. Впервые появилась красивая, удобная, продуманная, при этом простая и очень дешевая система офисного Wi-Fi стандарта 802.11n.
Единственно, чего не хватало — это встроенного биллинга для создания Hotspot. И вот, пару дней назад вышла новая версия, где все это есть. О ней и расскажу.

В этой статье описан один из способов настройки гостевых и корпоративных беспроводных сетей используя решения Enterprise Wi-Fi Ubiquiti UniFi и Cisco Integrated Services Routers

Постановка задачи.

Под термином “клиент” будем понимать зону ответственности за совокупность сетевых устройств.

Требуется обеспечить доступ для нескольких сотен клиентов к неким общим ресурсам в таком режиме, чтобы:

1. Каждый клиент не видел трафик остальных клиентов.
2. Неисправности одного клиента (broadcast-storm, конфликты IP-адресов, не санкционированные DHCP-сервера клиента и т.п.) не должны влиять на работу как других клиентов, так и всей системы в целом.
3. Каждый клиент не должен напрямую получать доступ к ресурсам других клиентов (хотя, как специальный случай, можно предусмотреть и разрешение данного трафика, но с его централизованным контролем и/или управлением ).
4. Клиенты должны иметь возможность получения доступа к общим внешним ресурсам (которыми могут быть как отдельные сервера, так и сеть Интернет в целом).
5. Общие ресурсы должны также иметь возможность доступа к ресурсам клиентов (конечно при условии, что известен общему ресурсу известен IP-адрес ресурса клиента).
6. Адресное пространство для клиентов выделяется централизованно и его администрирование не должно быть чрезмерно сложным.

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

Не секрет, что окончание поддержки Windows Server 2003 все ближе. День Х назначен на 17 июля 2015 года, а значит остается все меньше времени, чтобы успеть перевести свою инфраструктуру на более современные версии операционной системы. На Хабре мы уже делали несколько анонсов об окончании поддержки, на портале Microsoft Virtual Academy опубликован курс по материалам Jump Start, есть перевод статьи о переносе файлового сервера. В этой статье будет рассказано о миграции Active Directory и приведен пошаговый алгоритм, которым поможет вам при реализации переноса.

Что такое DKIM и как оно работает

DKIM (расшифровывается как DomainKeys Identified Mail) — метод идентификации письма по доменным ключам.
DKIM настраивается на почтовом сервере для того, чтобы подписывать исходящие письма цифровой подписью. Наличие такой подписи в заголовке отправленного письма сообщает серверу-получателю, что оно действительно было отправлено с указанного домена.
Известно, что в СПАМ-письмах часто в поле From: ставят е-mail, не имеющий совершенно никакого отношения к отправителю. В этом случае DKIM поможет распознать реальное письмо от спама. В отличие от других методов цифровой подписи письма, DKIM совместим с существующими форматами и протоколами и может быть плавно интегрирован в имеющиеся системы доставки и получения почты.

Подпись письма происходит на SMTP-сервере с помощью секретного ключа (Private key), а расшифровка подписи происходит на сервере-получателе или клиентской программе с помощью публичного ключа (Public key). Что интересно, публичный ключ хранится в DNS, что позволяет убить сразу двух зайцев. Во-первых, нет необходимости прикладывать Public key с каждым письмом для его расшифровки. А во-вторых, в таком случае DKIM позволяет сообщать серверам-получателям что делать с письмом, которое не имеет цифровой подписи, но якобы отправлено от вас. Эта технология называется ADSP (Author Domain Signing Practices). ADSP также хранится в DNS SMTP-сервера и доступен всем и отовсюду.

Аудит доменных служб Active Directory в Windows Server 2008 R2

ИТ среда не является статичной. Ежеминутно в системах происходят тысячи изменений, которые требуется отследить и запротоколировать. Чем больше размер и сложность структуры, тем выше вероятность появления ошибок в администрировании и раскрытия данных. Без постоянного анализа изменений (удачных или неудачных) нельзя построить действительно безопасную среду. Администратор всегда должен ответить, кто, когда и что изменил, кому делегированы права, что произошло в случае изменений (удачных или неудачных), каковы значения старых и новых параметров, кто смог или не смог зайти в систему или получить доступ к ресурсу, кто удалил данные и так далее. Аудит изменений стал неотъемлемой частью управления ИТ инфраструктурой, но в организациях не всегда уделяют внимание аудиту, часто из-за технических проблем. Ведь не совсем понятно, что и как нужно отслеживать, да и документация в этом вопросе не всегда помогает. Количество событий, которые необходимо отслеживать, уже само по себе сложность, объемы данных велики, а штатные инструменты не отличаются удобством и способностью упрощать задачу отслеживания. Специалист должен самостоятельно настроить аудит, задав оптимальные параметры аудита, кроме того, на его плечи ложится анализ результатов и построение отчетов по выбранным событиям. Учитывая, что в сети запущено нескольких служб – Active Directory/GPO, Exchange Server, MS SQL Server, виртуальные машины и так далее, генерирующих очень большое количество событий, отобрать из них действительно необходимые, следуя лишь описаниям, очень тяжело.
Как результат, администраторы считают достаточными мероприятия резервного копирования, предпочитая в случае возникновения проблем просто произвести откат к старым настройкам. Решение о внедрении аудита часто принимается только после серьезных происшествий. Далее рассмотрим процесс настройки аудита Active Directory на примере Windows Server 2008 R2.

Тема завершения поддержки Windows Server 2003 на Хабре поднималась уже несколько раз. В продолжении серии статей, посвященных окончанию поддержки и предложений по переходу на более новые версии Windows Server (а именно, на Windows Server 2012 R2). В этой статье я проведу сравнение различных версий Windows Server (2003 R2, 2008 R2, 2012 R2), а вы уже сможете посмотреть и решить, что выбрать для своей компании. Всех заинтересовавшихся жду под катом, но предупреждаю: вся сравнительная информация содержится в больших и длинных таблицах, которые вы сможете увидеть, нажав на спойлеры.

Введение

Достался нам настоящий динозавр, — HP ProLiant DL380 G4 Packaged Cluster with MSA500 G2, это готовое решение от Hewlett Packard, два сервера с внешним хранилищем, подразумевающее построение кластера. Ну что ж, кластер так кластер, сказано сделано. Ранее опыта создания подобных систем не было, так что постараюсь описать процесс как можно подробней со всеми допущенными нами ошибками.

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

• Общее понимание Multicast
• Протокол IGMP
• Протокол PIM
• >>>PIM Dense Mode
• >>>Pim Sparse Mode
• >>>SPT Switchover — переключение RPT-SPT
• >>>DR, Assert, Forwarder
• >>>Автоматический выбор RP
• >>>SSM
• >>>BIDIR PIM
• Мультикаст на канальном уровне
• >>>IGMP-Snooping
• >>>MVR