• Разворачиваем сеть тонких клиентов Thinstation с подключением к серверу Windows Server 2012 R2 Remote Desktop Services

    Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP.

    Читать далее…

  • Высоко-доступный балансировщик ZEVENET Load Balancer Community Edition 3.10.1 на базе виртуальных машин oVirt c 64-битной ОС Debian GNU/Linux 8.6

    В Марте этого года было объявлено о доступности Zen Load Balancer Community Edition 3.10, где была добавлена поддержка Debian Jessie, удалена поддержка профилей GSLB и TCP (вместо этого предлагается использовать L4xNAT), исправлены некоторые ошибки. Полный список изменений можно посмотреть в Changelog. Однако не узрев для себя существенных изменений, мы решили не связываться с обновлением ранее описанного форка ZenLB, адаптированного под 64-битную OC Ubuntu Server 14.04.

    Читать далее…

  • Расширение правил iptables на хостах oVirt 4.0

    В одной из прошлых заметок я описывал пример установки набора утилит HP System Management Tools на физическом сервере HP ProLiant DL360 G5 с ОС CentOS Linux 7.2. Некоторое время спустя этот же сервер был использован в качестве хоста виртуализации и на нём были развёрнуты компоненты oVirt Hosted Engine. Недавно хост был выведен в обслуживание и на него из онлайн репозиториев были установлены обновлённые версии пакетов, а в число обновлённых пакетов вошли и пакеты с утилитами HP. После установки я решил проверить работоспособность обновлённых утилит и попытался открыть веб-узел HP System Management Homepage. Однако из этого ничего не вышло, так как хост попросту блокировал обращения на порт TCP 2381.

    Читать далее…

  • Настройка Network Bonding с LACP между CentOS Linux 7.2 и коммутатором Cisco 3560G

    imageНа серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. C точки зрения повышения доступности и балансировки нагрузки, более эффективными методом использования нескольких сетевых интерфейсов сервера является объединение этих интерфейсов в логические сущности с использованием технологий Network Bonding и Network Teaming.

    В этой заметке на конкретном примере мы рассмотрим то, как с помощью технологии Network Bonding в ОС CentOS Linux 7.2 можно организовать объединение физических сетевых интерфейсов сервера в логический сетевой интерфейс (bond), а уже поверх него создать виртуальные сетевые интерфейсы под разные задачи и сетевые службы с изоляцией по разным VLAN. Агрегирование каналов между коммутатором и сервером будет выполняться с помощью протокола Link Aggregation Control Protocol (LACP) регламентированного документом IEEE 802.3ad. Использование LACP, с одной стороны, обеспечит высокую доступность агрегированного канала, так как выход из строя любого из линков между сервером и коммутатором не приведёт к потери доступности сетевых сервисов сервера, и с другой стороны, обеспечит равномерную балансировку нагрузки между физическими сетевыми интерфейсами сервера. Настройка в нашем примере будет выполняться как на стороне коммутатора (на примере коммутатора Cisco Catalyst WS-C3560G), так и на стороне Linux-сервера с двумя сетевыми интерфейсами (на примере сервера HP ProLiant DL360 G5 с контроллерами Broadcom NetXtreme II BCM5708/HP NC373i)

    Читать далее…

  • Windows Server 2012 R2 Remote Access — Настраиваем VPN сервер на использование протокола SSTP

    Прошло уже более года, после того как мы начали работу с VPN соединениями на базе протокола L2TP/IPsec и авторизацией через RADIUS. Накопился некоторый опыт использования описанной конфигурации, были выявлены её плюсы и минусы, сделаны определённые выводы. Опираясь на эти выводы, в данной заметке мы продолжим развитие темы настройки безопасных VPN соединений и рассмотрим шаги, необходимые для организации возможности работы по протоколу SSTP (Secure Socket Tunneling Protocol).

    Читать далее…

  • Балансировщик Zen Load Balancer (ZenLB) и логи на Back-End веб-серверах IIS

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

    Читать далее…

  • Высоко-доступный балансировщик Zen Load Balancer (ZenLB) Community Edition на базе 64-битной ОС Ubuntu Server 14.04

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

    Читать далее…

  • Распределение трафика между двумя прокси-серверами Squid (на Ubuntu Server 14.04.2 LTS) подключёнными к двум интернет-провайдерам (Multi-WAN). Обновлённый вариант.

    image

    В общем случае для организации балансировки трафика между двумя WAN-интерфейсами на Ubuntu можно использовать способы описанные в документе Ubuntu-ru — IP-Балансировка: объединяем несколько интернет-каналов в один. В нашем случае требуется организовать немного более простую конфигурацию и поэтому способ её реализации будет несколько более прост. На уже работающих прокси-серверах Squid, собранных в конфигурацию повышенной доступности, имеется по одному WAN-интерфейсу направленному в сторону одного интернет-провайдера. Для повышения доступности Интернет для конечных пользователей мы добавим на прокси-серверы ещё по одному WAN-интерфейсу направленному в сторону другого интернет-провайдера и настроим скрипт перестроения правил маршрутизации в случае возникновения проблем с одним из провайдеров. Здесь мы рассмотрим обновлённый вариант такой настройки (без использования multipath-маршрутизации).

    Читать далее…

  • Повышаем доступность прокси-сервера Squid с помощью UCARP с балансировкой нагрузки между двумя виртуальными серверами на базе Ubuntu Server 14.04.2

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

    Читать далее…

  • Windows Server 2012 R2 Remote Access — Настраиваем VPN сервер с двухфакторной аутентификацией на базе L2TP/IPsec и авторизацией через RADIUS

    imageВ этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя

    Читать далее…