Краткая шпаргалка:

HOST1: ip link add grelan type gretap  local <IP1> remote <IP2>
HOST1: ip link set grelan up
HOST1: iptables -I INPUT -p gre -s <IP2> -j ACCEPT
HOST2: ip link add grelan type gretap local <IP2> remote <IP1>
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s <IP1> -j ACCEPT

Четыре команды на туннель и две на firewall (не нужны если трафик между своими серверми уже разрешен)
Это всё что нужно, дальше длинное объяснение с подробностями.

Тема «Умный дом» уже у всех на слуху. Про неё говорят, в неё вкладывают, её развивают… По этой теме к таким гигантам как Siemens, General Electric и др. присоединились, казалось бы, не совсем профильные компании, такие как Microsoft, Google, Apple.

Единого стандарта по теме нет, равно как нет инструкции, мол, «делай так и вот так», поэтому теоретически построить свой умный дом может каждый и именно так, как ему захочется и потому эту тему я не смог пропустить и активно к ней подключился. Не скажу, что с умными домами я собаку съел… нет, скорее так, понадкусывал, но тем не менее, на основе свое опыта и своих наблюдений попробую выложить развёрнутый… ммм… How-To? Нет, не потянет. Обзор? Тоже не то… Скорее это будет напутствие или некий набор советов.

Театр начинается с вешалки, а я начну с того, что сразу расставлю все точки над «И», чтобы у читателей не возникало в процессе чтения необоснованного негатива или просто какого-то недопонимания.

Самое главное — это то, что статья рассчитана на людей, которые толком ещё не поняли, нужен ли им вообще этот самый «Умный дом» и нужно ли влезать в эту тему?

Теперь термин.
Будем честны, «Умный дом» — это не только такая система с искусственным интеллектом, которая разговаривает с Вами по утрам в ванной (пока вы бреетесь) и готовит Вам ужин пока вы едете домой. Не нужно путать систему с женой.

Фирма, в которой я работаю, для IP-телефонии использует в том числе и Cisco Unified Communications Manager (CUCM). В один прекрасный момент мне понадобилось автоматически отслеживать состояние телефонов — а именно, зарегистрированы ли они, находятся ли они в Hunt Group и т.п. Несколько часов усиленного гуглежа, собирание скудной информации по кусочкам, и начали появляться более-менее работоспособные скрипты. Ими я и поделюсь в этой статье. Версия моего CUCM — 7.1.5, IP-адрес предполагается 10.0.0.10. Скрипты будут на PHP, но можно запросто переписать на любой другой язык.

Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).


Рис. 1

Давайте пробежимся с MTU по уровням OSI:

Случилось так что в компании, из-за перебоев электропитания, несколько раз падали сервера, а администраторы узнавали об этом только утром когда сотрудники не смогли приступить к работе.

Основной проблемой стало то, что все уведомления администраторам отправлялись по почте — которая, как можно с легкостью догадатся, тоже лягла.

Тогда у меня и зародилась идея — «А давайте админам звонить в критических ситуациях!»

За реализацией и скриптами — прошу под кат.

Новая сетевая задачка из необычных.

Вот упрощённая топология:



Имеем опорную сеть, с запущенным MPLS TE. Поверх сети организована услуга VPLS для крупного клиента.
Между маршрутизаторами натянуты TE-Туннели, в которые трафик VPLS заворачивается с помощью политик.

Какое оборудование стоит за нашими маршрутизаторами, можно только догадываться, но мы доверяем их QoS меткам и знаем, что основной тип трафика идёт с метками EF.

Одним чудесным утром всё пропало — два линка, изображённые красным, упали (физически, порвали оптику, например). И как бы логично, что стали недоступны узлы 2 и 3. Но вот странность: вслед за ними клиент стал жаловаться на проблемы с узлом 4 — сервисы тоже перестали работать. После восстановления повреждённых линий всё починилось на всех узлах.

Внимание, знатоки, вопрос: кто виноват и что делать?

Предисловие

В нашей организации в качестве почтового сервера используется замечательный (мое мнение, может быть, ошибочное) продукт — Communigate Pro (CGP). В прежние времена мониторинг работы серверов осуществлялся штатными средствами Communigate + logwatch для мониторинга операционной системы. Сейчас к этим средствам добавился Zabbix. Все основные аспекты операционной системы мы отслеживаем при помощи Zabbix-агента, а статистику с CGP — при помощи SNMP-запросов. Эти способы охватывают практически все необходимые параметры системы. Но есть некоторые характеристики, которые просто так отслеживать не получится. В частности, для нас очень важны такие характеристики, как количество сообщений в очереди в конкретный домен и/или на определенный хост. В интерфейсе администратора CGP есть возможность эти очереди отслеживать, но хотелось бы, чтобы всю информацию можно было мониторить в одном месте. Итак, как же это сделано у нас.

Когда объявляется крупный онлайн тендер, иногда случается так, что одна заявка приходит довольно быстро, а затем площадка с тендером ложится под крепкой DDoS атакой. Атака странным образом заканчивается в момент окончания тендера. Поскольку одна заявка поступила, именно она и выигрывает. С такой проблемой (как и с обычными DDoS атаками от недоброжелателей и шантажистов) сталкиваются многие наши корпоративные клиенты.

Теперь мы обеспечиваем защиту как сервис. Делается это на двух уровнях: установкой железа Radware DefensePro у клиента и при необходимости переключением трафика на наш центр очистки.



Максимальная мощность атаки — 80 Гб/с (на уровень приложений, более мощные тоже фильтруются, но уже без гарантий по отсутствию потерь легитимного трафика), планируем по мере необходимости расширять до 160. Время от начала до отражения атаки на стороне клиента — 18 секунд максимум, на стороне центра очистки данных — до 40 секунд с учётом времени переключения трафика. При переключении потерь трафика не происходит.

Как работают системные администраторы, что используют в своем повседневном труде, какие утилиты облегчают нам жизнь?
Мы постараемся вкратце ответить на эти вопросы и описать, как устроена наша работа.

Итак, что в принципе, должен делать (уметь делать) системный администратор:
Устанавливать/обновлять/удалять ПО
Настройку ПО
Планировать работы
Документировать
Мониторить состояние ИТ-систем
Диагностировать и поддерживать ИТ-системы
Резервное копирование/архивацию ПО и данных

Для всего этого есть немало различного ПО, постараемся описать все самое необходимое.

Доброго времени суток всем!
В этой статье хотел бы поделиться опытом в одном не самом тривиальном вопросе: как подключить коробочный IPS к многоуровневому коммутатору в режиме Inline. Речь пойдёт именно о «железном» исполнении IPS в виде апплаинса (отдельной коробки) и именно о его Inline-внедрении. Статья главным образом ориентирована на оборудование Cisco: IPS 4510 и Catalyst 6500.

В предыдущих статьях я поднимал тему о возможности эффективного использования связки RAWTherapee + GIMP в практике фотолюбителя, не желающего связываться со взломанными продуктами или переплачивать за отчасти ненужную функциональность Adobe Photoshop. Применение RAWTherapee во многих случаях предпочтительнее, чем использование встроенной утилиты Adobe Camera Raw, и во всех известных мне случаях обеспечивает более быстрый и как минимум не менее качественный результат, чем поставляемые с камерами конвертеры. (Исключением является здесь, пожалуй, Olympus Viewer, чудовищно медленный, но зато способный в полной мере дать пользователю прочувствовать знаменитую «магию фирменных цветов Olympus». О том, как этого достигнуть с использованием RAWTherapee, будет сказано чуть ниже.)

Введение

Несколько месяцев назад у меня появилось несколько устройств Cisco ASA разных моделей. После их настройки у меня встал вопрос о подсчете трафика, который будет проходить через них. Решил вести учет при помощи стандартного протокола NetFlow, который поддерживается этим оборудованием. Но вот незадача, по сей день в свободном доступе для учета трафика нет ни одного бесплатного решения, которое может нормально считать и учитывать трафик по пользователям.

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

Первое, с чего пришлось начать, это с изучения данной статьи — http://habrahabr.ru/post/127613/ (автору gag_fenix большущий респект). Это единственная нормальная и полная статья о том, как можно получить и учитывать трафик на сетевом оборудование Cisco ASA с использованием nfdump. В этой статье отлично описана только реализация о том, как можно настроить оборудование на передачу пакетов NetFlow на хост, а также каким образом можно использовать полученные данные для последующего анализа. Сам же анализ трафика и его учет не рассматривается в статье.

Перед тем, как читать дальше, настоятельно рекомендую хорошо изучить вышеуказанную статью, так как некоторые особенности настройки будут опускаться. В статье рассмотрим такие вопросы о том, как вести учет по NetFlow (используя MySQL на коллекторе), как посчитать VPN трафик, какой тип пакетов учитывать, как избежать «удвоения» и «дублирования» трафика, и как использовать мое приложение.

Большинство реализаций списков доступа подразумевает под собой поведение «всё что не разрешено, то запрещено». Разумный подход, с учётом того, что при проектировании мы заранее ожидаем тот или иной тип трафика в определённом направлении: если у нас подключен абонент или пиринговый партнёр, значит данных с других IP на этом интерфейсе быть не должно, а если у нас подключен Интернет, откуда там взяться частным адресам? А может зря всё это? Может и нет никакого паразитного трафика и безусловный запрет в ACL это только перевод ресурсов. Ведь клиентам оператор сам выдаёт адреса, а пиринговые партнёры и апстрим провайдеры братья связисты, которые должны понимать всю сложность и щекотливость ситуации. К сожалению, это совсем не так.
Участники круглого стола посвящённому DDoS, прошедшего на YaC2013 очень сетовали на то, что при всех существующих рекомендациях никто не старается заниматься безопасностью своих сетей. То есть начинать надо в первую очередь с себя (с операторов связи), как минимум бороться с IP-спуфингом.
От чего же защищает deny ip any any можно посмотреть далее, просто примеры из журналов мониторинга.

Добрый день.
Хочу написать о проблеме с которой я столкнулся около года назад. Для нашего проекта выделели аккаунт на AWS и было решено перевести процесс разработки в облако. Все удобно, виртуальные сервера разворачиваются и настраиваются шустро, но чем дальше мы двигались в production тем острее акцентировался вопрос о мониторинге. Новые сервера добавлялись каждый день, а в продакшне еще планировался автоскейлинг.

На всякий случай, кототкое описание:

Как-то один из персонажей популярного сериала заявил «Все врут!». И это отчасти правда. И что уж 100% правда, что все лажают. Каждый может вспомнить, когда наши сотрудники не выполнили взятые на себя обязательства, сорвали сроки, что-то сделали — но совсем не то, а иногда лучше бы вообще не проявляли инициативу. К сожалению, лажают не только сотрудники, но и руководители. Самое печальное в этом то, что работают далеко не дураки, но бывают такие глупые epic fail, что и говорить не хочется.



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

Множество стоек, каждая плотно упакована серверами, маршрутизаторами, коммутаторами и прочими kvm'ами.
Нужен какой-нибудь удобный способ рулить всем этим хозайством, быстро подключаться к нужному оборудованию и
производить его настройку. Прямо чтобы пара кликов мышью и оп — перед тобой консоль нужного коммутатора.

Для мониторинга наших подопечных мы используем Zabbix.
Так почему бы не приспособить сей дивный инструмент и для этой задачи.
Ведь было бы очень удобно ткнуть в карте Zabbix на нужную стойку, перейти на её подкарту и, выбрав железку,
запустить локальный ssh/telnet/vnc клиент на своем компьютере.

Озадачившись идеей, я начал мучать поисковые машины в надежде отыскать варианты реализации.
Был найден данный тред на форуме Zabbix, но мне хотелось запускать именно локальные программы на моей машине кликом по ссылке в карте.
Еще некоторое время поплутав по закоулкам всемирной паутины и помучав знакомых программистов глупыми вопросами я вспомнил о… Python.
Да, Python, не раз пришедший на помощь в трудную минуту.
Питаю очень нежные чувства к этому языку за его простоту и приятный теплый синтаксис.

И так, вектор атаки изменился и поисковики замерли в ожидании нового вброса мыслеобразов…
Спустя некоторое время я уже четко представлял как буду решать задачу — напишу клиент-серверное приложение!
На моем компьютере будет ждать команд серверная часть, а на сервере мониторинга, при клике по ссылке, будет запускаться клиент и передавать нужную команду.

Результатом изысканий стало кроссплатформенное приложение, работает как на Linux, так и на Windows.
Эпопея проб и ошибок на пути к заветной цели ждет вас под хабракатом.

В этом посте я хотел собрать воедино всю информацию по системе сертификации RPKI, но тема оказалась достаточно обширной, кроме того наткнулся на несколько статей в русскоязычной части интернета в которых подробно описывается принцип работы RPKI (ссылки на эти статьи в конце поста). С примерами настройки и применения RPKI на живом железе все хуже. Поэтому решил сделать статью в стиле HOW-TO. Информация, представленная в статье, может помочь провайдерам автоматизировать процесс проверки получаемых префиксов от клиентов и исключить ошибки в фильтрах. Всех кому интересна защита динамической маршрутизации средствами RPKI и настройка RPKI кэш-сервера на Linux прошу под кат.

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

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

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

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

Наверное, лучше обо всем по порядку.

Недавно я озадачился поиском возможности создания шифрованного подключения к своему офису средствами L2TP/IPsec протокола. Задача усложнилась, когда, кроме Windows клиентов, появилась потребность пускать в сеть еще iOS и Android клиентов. В Интернете множество статей как проделать это на Windows Server с «внешним» IP-адресом. Но я хочу предложить сообществу реализацию стандартными средствами Windows 7/8 шифрованного L2TP тоннеля в локальную сеть с популярной, на мой взгляд, топологией.

В наш век общедоступных зеркальных и беззеркальных камер с разрешением матрицы от 16 мегапикселей и выше домашний фотоархив запросто может стать тем местом, где, как говорится, сам чёрт ногу сломит. В силу одних только размеров хранящихся в нём файлов, фотоархив запросто может забить не только диск ноутбука, но и средних размеров NAS или многодисковый внешний накопитель. Между тем, для фотографа, если он только не «бомбила», едва ли не всякий сделанный снимок имеет ценность; покажется сейчас, что вот эта вот нерезкая штуковина годится только для корзины, ан нет — через пару лет выяснится, что из этого снимка может выйти неплохой коллаж! О ностальгических воспоминаниях, привезённых в цифровом формате из Франции, Египта, с последнего звонка, со свадьбы троюродного брата первой тёщи в деревне Малые Дозы и так далее — я вообще не упоминаю. Это проходит по категории «хранить вечно».