И снова всем привет! Сегодня речь пойдет о протоколах верхнего уровня. Разберем, как они работают, из чего состоят и где применяются теоретически и на практике.

В последнее время приходится часто настраивать с нуля маршрутизаторы Cisco (в основном 800-1800 серии) для филиалов моей компании и дабы не набирать одни и теже команды третий десяток раз составил для себя небольшой шаблон настроек на разные случаи жизни. Сразу скажу что сертификаты от Cisco не получал, книжек по данным роутерам особо не читал, весь свой опыт приобрел методом научного тыка, курением мануалов на cisco.com и кое каким вдумчивым заимствованием кусков чужих конфигов…

В сети любого Интернет-провайдера можно встретить такой обязательный элемент, как кэширующий DNS сервис. А поскольку работа сети Интернет без службы DNS невозможно, серверов таких будет минимум два, с обязательным резервированием и балансировкой. В заметке я постараюсь описать один из вариантов балансировки нагрузки между несколькими кэширующими серверами на основе Cisco IP SLA.

В августе 2015 года компания Cisco Systems закончила покупку компании OpenDNS.

Безусловно, это одна из самых громких и удачных покупок в области информационной безопасности. Для клиентов Cisco – это беспрецедентная возможность очень просто и быстро повысить уровень безопасности всей организации. Добавляем в качестве внешних серверов разрешения доменных имён (DNS) пару айпишников OpenDNS – вот и всё, что надо для начала использования высоконадёжной и, главное, безопасной инфраструктуры фильтрации угроз на базе DNS-запросов.

Всем привет. На днях возникла идея написать статьи про основы компьютерных сетей, разобрать работу самых важных протоколов и как строятся сети простым языком. Заинтересовавшихся приглашаю под кат.

Иногда есть желание контролировать ситуацию в разнородных сетях, отдельных хостах за натом или просто мониторить компьютеры родителей или друзей, но ресурсов для этого почти нет. Будем искать решение с помощью icinga2. Сейчас у VDS провайдеров есть предложения VDS серверов в минимальных конфигурациях за смешные деньги. Что ж, воспользуемся этим.

Например, сервер с одним ядром, 512 Мб оперативной памяти и диском на 10 Гб обойдется всего в 90 рублей в месяц. Установим icinga2 на такой сервер. Но для экономии ресурсов не будем хранить данные и вместо стандартного веб-интерфейса (icingaweb2) сделаем свой который будет обращаться к API icinga2.

Eсли вкратце, то технология позволяет виртуальным машинам получать прямой доступ до физических устройств pci на сервере с гипервизором. Однако, при использовании этой технологии перестают работать почти все полезные вещи, которые позволяет кластер vSphere: fault tolerance, high availability, снапшоты, vMotion и DRS с ним же.

Более того, когда виртуальная машина использует устройство напрямую, минуя гипервизор, то это устройство перестаёт быть доступно самому гипервизору. Например, если прокидывать сетевушку внутрь виртуалки через DirectPath I/O, то, да, ресурсы гипервизора на обработку трафика от виртуальной машины больше не используются — это хорошо. Плохо то, что прокинутую сетевушку сможет использовать только одна виртуалка. Технология, получается, весьма спорная, если не сказать больше — бесполезная. Но не всё так однозначно.

Занимаясь восстановленными (refurbished) серверами, мы накопили приличный опыт общения с проблемами разных брендов, которым хотим поделиться на примере машин большой тройки: Dell, HP и IBM. Чтобы никому не было обидно, мы пойдём в алфавитном порядке.



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

Мы продолжаем цикл публикаций о проблемах, с которыми сталкиваемся при подготовке refurbished-серверов. Ранее мы писали о серверах DELL, на этот раз речь пойдёт о продукции HP. Все эти проблемы решались нашими инженерами, и это лишь малая часть сюрпризов, которые могут преподнести серверы этого вендора. Однако, если вы самостоятельно занимаетесь обслуживанием серверов, то, возможно, наш опыт может вам пригодиться.

В преддверии подкаста про VoIP внезапно родилась небольшая заметка.

Иногда приходится сталкиваться с проблемой установки голосового вызова. По неизвестной изначально причине, звонок просто рвётся.

Что делать, если методы влоб уже использованы?

Дамп.
А что сейчас неразрывно связано с дампами? Wireshark.

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

Многие я думаю читали о применении Elasticsearch, Logstash и Kibana для сбора и анализа логов, но часто статьи начинаются с длинного мануала как поднять сервисы ELK и заставить работать их совместно.
Здесь я хочу рассказать о быстром старте с помощью Docker.

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

В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.

Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):

R1#sh ip rou | i 40.  
	 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O        40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O        40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0

Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:

 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.

Автор статьи — Андрей Каптелин, участник ИТ-сообщества

С выходом Windows Server Technical Preview 2 многие службы получили обновления. Не обошли обновления стороной и заслуженный сервер имен DNS. Помимо поддержки управления DNS-сервером из PowerShell, появилась новая возможность – DNS policy.

DNS policy – это расширение DNS-сервера для адаптации его работы в зависимости от содержания приходящих запросов. Благодаря первоочередному применению политик на поступивший запрос, можно существенно облегчить работу сервера, отсеяв заведомо ненужные запросы, либо указав серверу, изменить содержание ответа в соответствии с описанными правилами.

Привет, %хабрачитатель%!

Несколько месяцев назад у нас возникли проблемы с одной виртуальной машиной, запущенной на сервере Dell PowerEdge R720 с ESXi 5.5. Перезагрузка этой VM длилась довольно долго и вызвала сильное падение производительности на самом хосте.
Lifecycle-лог на сервере был наполнен сообщениями вида:

PDR47
A block on Disk 0 in Backplane 1 of Integrated RAID Controller 1 was
punctured by the controller.

PDR64
An unrecoverable disk media error occurred on Disk 0 in Backplane 1 of
Integrated RAID Controller 1.

Гугление привело к неутешительному выводу: рейд-массив поврежден и восстановить его невозможно. А именно — повредились данные, относящиеся к одному блоку (страйпу), сразу на нескольких дисках (double fault):

К счастью, делловские RAID-контроллеры обладают фичей продолжать работу, несмотря на неконсисентное состояние массива — puncture (https://www.dell.com/support/Article/us/en/04/438291/EN#Unique-Hyphenated-Issue-Here-2), что позволяет сохранить хотя бы ту часть данных, которая не повредились. Это, конечно, не никак отменяет необходимость последующей замены дисков и пересборки рейд-массива «с нуля».
Для предотвращения подобных ситуаций Dell рекомендует запускать проверку целостности массива не реже одного раза в месяц. Увы, но мы об этом узнали слишком поздно.

Такую проверку можно запускать как через веб-интерфейс Dell OpenManage Server Administrator (http://www.dell.com/support/contents/us/en/19/article/Product-Support/Self-support-Knowledgebase/enterprise-resource-center/Enterprise-Tools/OMSA/), так и через утилиты omconfig/omreport, входящие в OMSA. И, если бы разработчики из Dell не «забыли» включить эти утилиты в OpenManage для ESXi, то проблем с автоматизацией бы не возникло, т.к. понятно, что ручная проверка целостности массива на каждом сервере, совершенно не IT-way. Не говоря уже о том, что интерфейс OMSA очень медленный и работать с ним удовольствие еще то.
Ребята из Dell «поработали на славу» и простым способом автоматизировать проверку (например, через открытие в cURL заранее подготовленной ссылки) невозможно, т.к. веб-интерфейс генерируется динамически и постоянные ссылки в нем отсутствуют.

Что же делать?

Однажды мне захотелось управлять одним из домашних компьютеров удаленно, но при этом взаимодействовать с текущим пользователем, но компьютер был довольно слабый и при запуске например TeamViewer’а нагрузка процессора поднималась до 98% и компьютер начинал заметно тормозить. Попробовал стандартный RDP, но тогда «выбивался» текущий пользователь и для входа локально приходилось набивать пароль. Но чуть позже мне случайно попалась команда shadow.

Перевод

1. Введение

   
   Существуют различные способы изучения технологий: чтение книг, участие в конференциях, создание примеров и другие. Я считаю одним из лучших способов — создать что-то полезное для себя с использованием изучаемой технологии. Блог одна из полезных вещей, которую вы можете легко сделать. В серии статей, мы изучим ASP.NET MVC, шаг за шагом, путем создания блога с нуля.
   

Не секрет, что в больших конторах тема фильтрации Интернета довольно актуальная. С этой задачей справляется немало программных и аппаратных решений. Но в настоящее время все те сайты, которые мы резали ранее, работают по протоколу HTTPS, т.е. порт 443. Как известно, данный протокол проследить, прослушать и т. п., невозможно. А любой кеширующий фильтрующий прокси-сервер, редиректор и т. п. фильтрует только HTTP, т.е. порт 80. Как же резать Вконтакте, Одноклассники, iphide.info и многие другие подобные сайты? Как блокировать доступ к личной почте в организации, если использование оной запрещено порядками в организации? Да, можно фильтровать по IP адресам, но они частенько меняются, да и на многих ресурсах несколько IP адресов. Блокировать их на уровне файрвола как-то совсем не православное решение, и не совсем удобное.

И вот, совсем недавно, мне один товарищ рассказал, что он поднимает у себя в конторе кеширующий прокси с фильтрацией HTTPS, меня это заинтересовало.

Довольно часто требуется балансировать нагрузку между несколькими веб-серверами. При этом, как правило, необходимо, чтобы веб-приложения получали реальные IP-адреса клиентов, а не IP балансировщика.

В случае балансировки и терминации HTTP(S)-трафика на HAProxy (Layer 7 [1]) данная задача легко решается добавлением заголовка “X-Real-IP” и его обработкой на Nginx при помощи модуля ngx_http_realip_module [2]. При балансировке TCP-трафика от HTTPS-клиентов и передаче его на веб-сервера напрямую без модификации или терминации (Layer 4 [3]) добавить данный заголовок невозможно, поэтому требуется воспользоваться возможностями, предоставляемыми Proxy Protocol [4, 5, 6].

Рассмотрим оба варианта (балансировка L7 и L4) на примере выдержек из конфигурационных файлов haproxy 1.5.9 и nginx 1.6.2

Внезапно я узнал что Microsoft выпустил «бесплатный» облачный DPM. 7 октября только на английском, 2 декабря выпустили версию с поддержкой кучи языков (русский в их числе). Скачать можно тут. Документация тут.