Привет! Сегодня расскажу, как настроить GNS3 сервер в облачных сервисах. А в конце будет небольшой FAQ по GNS3. Для примера был выбран Google Compute Engine (GCE) (из-за бесплатного двухмесячного триала и более низких цен на виртуалки в Европе по сравнению с AWS).

Почему вообще стоит заморачиваться?

Один раз попробовав, я больше не запускаю GNS3 локально. Нет смысла забивать оперативку своего ноутбука лабой. Кроме того, я могу запускать свои CCIE лабы с любого компьютера (в моём случае рабочий и домашний ноутбуки) — неважно, сколько RAM/какой CPU. При этом, локальные файлы лаб я сохраняю в Dropbox, что позволяет мне продолжать работать над той же лабой с разных устройств.

Под катом вы найдёте подробную инструкцию по установке GNS3 в GCE.

Недавно передо мной встала задача протестировать приложение, написанное на Bash. Изначально я решил использовать unit-тесты на Python, однако, мне не захотелось добавлять лишние технологии в проект. И пришлось выбирать тестовый фреймворк, родным языком которого является многострадальный Bash.

Вместо предисловия

Сегодня приснился сон, как-будто меня ужали до размера нескольких
килобайт, засунули в какой-то сокет и запустили в контейнере.
Выделили транспорт в оверлейной сети и пустили
тестировать сервисы в других контейнерах…
Пока не сделали docker rm

Не так давно мне посчастливилось стать членом очень крутой команды
Centos-admin.ru, в которой я познакомился с такими же, как я: единомышленниками со страстью к новым технологиям, энтузиастами и просто отличными парнями. И вот, уже на второй рабочий день меня с коллегой посадили работать над одним проектом, в котором требовалось «докерировать всё, что можно докеризировать» и было критически важно обеспечить высокую доступность сервисов.

Скажу сразу, что до этого я был обычным комнатным Linux-админом: мерился аптаймами, апт-гет-инсталлил пакеты, правил конфиги, перезапускал сервисы, тайлил логи. В общем, не имел особо выдающихся практических навыков, совершенно ничего не знал о концепции The Pets vs. Cattle, практически не был знаком с Docker и вообще очень слабо представлял, какие широкие возможности он скрывает. А из инструментов автоматизации использовал лишь ansible для настройки серверов и различные bash-скрипты.

Ключевые моменты:
* Реализация скрипта для проверки PTR посетителей;
* Конфигурирование nginx в IfIsEvil-style с ветвлениями map;
* Имена location в переменных map;
* Управление ветвлением через try_files /nonexist $map_var.

Многие высоконагруженные и популярные сайты страдают от того, что кроме живых посетителей их посещают разнообразные парсеры, боты и прочие автоматические сканеры, которые не несут никакого полезного эффекта, а только создают паразитный трафик и нагрузку на, и без того, нагруженную систему. В данном случае я не имею виду поисковых ботов, которые хоть и зачастую нагружают проект не нормировано, но просто необходимы любому проекту.
Один из наших клиентов регулярно испытывал проблему лавинообразного роста нагрузки в определенное время суток. Периодически, раз в сутки и чаще происходили наплывы посещений со значительным ростом LA на серверах. Было принято решение построить защиту от паразитного трафика.

Не так давно подключили дополнительного провайдера в виде беспроводной йоты, простого «свистка». Имеем Mikrotik CCR1009-8G-1S-1S+, на котором есть usb. Но возникла проблема, йота периодически зависает и пока не перезагрузишь — ничего не работает. Обращался в техническую поддержку Йоты, предложили купить роутер Zyxel, либо поставить между йотой и микротиком устройство которое будет отключать и включать электропитание 1 раз в сутки. Покупать дополнительный роутер который будет использоваться для йоты никто не хотел, а ставить переключатель тоже не вариант-вдруг йота подвиснет днем, а переключатель настроен на 23:00. Конечных решений для данной проблемы в ресурсах сети не нашел (а возможно плохо искал). Поэтому решено было настроить автоматический reset yota.

При эксплуатации системы GitLab CE на своем предприятии (имеющему большую филиальную структуру), была обнаружена уязвимость, которая может привести к получению полного доступа к аккаунту любого пользователя системы администраторами филиалов предприятия.

Проблема выявлена в подсистеме LDAP-аутентификации пользователей. Дело в том, что основной сущностью, с использованием которой происходит авторизация в GitLab является E-Mail пользователя. Однако при входе пользователей в GitLab с использованием LDAP процесс аутентификации/авторизации происходит следующим образом:

• Пользователь вводит на странице Sign-In системы свои имя/пароль из службы каталогов LDAP (Active Directory).
• GitLab, используя введенные данные аккаунта производит аутентификацию пользователя в LDAP.
• В случае успешной аутентификации GitLab считывает из атрибута MAIL аутентифицированного аккаунта адрес электронной почты и авторизует по нему в GitLab без всяких дополнительных проверок

.
В результате, например, «нехороший» системный администратор «филиала A», может используя свои полномочия, к примеру в Active Directory, создать в своем OU «Филиал А» любого пользователя (например hackuser) и записать в его LDAP-атрибут MAIL адрес электронной почты пользователя любого другого филиала, на который даже не распространяются полномочия этого администратора. После этого «нехороший» администратор «Филиала А» может авторизоваться пользователем hackuser в системе GitLab, при этом в результате авторизации будет получен полный доступ к аккаунту пользователя, имеющего адрес электронной почты установленный «нехорошим» администратором для hackuser.

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

Пара примеров:

• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы решили взглянуть на западный опыт и кратко проанализировать тему балансировки нагрузки. Нас привлекла заметка на тему работы с DDoS-атаками.

В сентябре 2013 я опубликовал крайне популярную статью с таким-же названием. Однако с тех пор всё радикально поменялось со стороны fail2ban — добавлена поддержка asterisk «из коробки», а также с версии 0.9 радикально изменился формат конфигурационных файлов. Поэтому я публикую новую статью на эту тему, так как действия по настройке теперь тоже радикально иные.

До момента появления лога security в Asterisk 10-й версии fail2ban не мог корректно защищать asterisk от популярного вида атак — подбора sip пароля к экстеншенам, т.к. в обычных логах asterisk ip-адрес атакующего не отображался.
С появлением лога security эта проблема решена.

Если у вас Asterisk 10 и новее, его успешно можно использовать на пару с fail2ban. Настройка довольно простая.

Для тех кто использует Zabbix, и хочет научится делать свои шаблоны и мониторить не стандартные системы (которых еще нет в Zabbix), а также,
кому нужен расширенный мониторинг S.M.A.R.T., и кого не устроили уже существующие шаблоны, прошу под кат.

Известно, что при подключении к открытым Wi-Fi сетям ваш трафик может быть легко прослушан. Конечно, сейчас всё больше и больше сайтов используют HTTPS. Тем не менее, это ещё далеко не 100%. Возникает естественное желание обезопасить свой трафик при подключении к таким открытым Wi-Fi сетям.

Популярное решение этой проблемы — подключение через VPN. В таком случае ваш трафик передается в зашифрованном виде до VPN-сервера, и уже оттуда идет в интернет.

У такого решения есть небольшой недостаток: пока VPN-подключение ещё не установлено, все приложения на вашем компьютере (включая открытые вкладки браузера) получают доступ в интернет в обход VPN-подключения.

В этой статье я расскажу, как можно этого избежать.

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

ДАНО:

маломощная железка с arm процессором и собранный под нее и установленный Debian 7 wheezy.

ЗАДАЧА:

поставить FreeRADIUS 3.0.X, настроить его на работу с БД SQLITE. Т.е., учетные записи пользователей (которых нужно аутентифицировать) RADIUS должен брать из БД SQLITE.

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

Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.

Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.

После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.

В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.

При классической схеме подключения двух ISP к одному роутеру, есть возможность использовать сразу два канала для NATирования внутренних клиентов с балансировкой нагрузки, а не только для фейловера при отказе одного из провайдеров.

Содержимое: как сделать так, чтобы компьютер отвечал в интернете на все свои IP-адреса по всем своим интерфейсам, каждый из которых имеет шлюз по умолчанию. Касается и серверов, и десктопов.

Ключевые слова: policy routing, source based routing

Лирика: Есть достаточно статей про policy routing в Linux. Но они чаще всего разбирают общие, более тонкие и сложные случаи. Я же разберу тривиальный сценарий следующего вида:



Нашему компьютеру (серверу) доступно три интерфейса. На каждом интерфейсе шлюз ему выдал IP (статикой или по dhcp, не важно) и сказал «весь трафик шли мне».

Если мы оставим эту конфигурацию как есть, то будет использоваться принцип «кто последний встал, того и дефолтный шлюз». На картинке выше, если последним поднимется нижний интерфейс (241), то в него будет отправляться весь трафик. Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

Другими словами, в обычном варианте будет работать только один интерфейс. Чтобы сделать ситуацию хуже, если адреса получены по dhcp, то обновление аренды на других интерфейсах может перезаписать шлюз по умолчанию, что означает, что тот интерфейс, который работал, работать перестанет, а начнёт работать другой интерфейс. Удачной стабильной работы вашему серверу, так сказать.

Решение

Введение

Привет всем! Несколько месяцев назад на Хабре была опубликована статья «Вещание онлайн-видео с помощью nginx» , в которой Aecktann рассказал о своем опыте внедрения разрабатываемого мной модуля к nginx для вещания видео — nginx-rtmp-module. С тех пор продукт активно развивался и в этой статье я более подробно расскажу о нем.

Вещатель нужен для передачи видео-потока клиенту. Речь идет либо о живом потоке, либо о вещании записанного видео (VOD, Video-on-demand). Существует большое количество технологий вещания видео. Среди них можно выделить традиционные протоколы, такие как RTMP или MPEG-TS, а также появившиеся в последнее время технологии адаптивного вещания поверх HTTP. К последним относятся HLS (Apple), HDS (Adobe), Smooth Streaming (Microsoft), MPEG-DASH. При выборе технологии основным фактором является ее поддержка на клиентской стороне. Именно поэтому вещание в формате RTMP на текущий момент является одним из самых распространенных. Протокол HLS поддерживается устройствами компании Apple, а также некоторыми версиями Android.

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

А что если при входящем звонке вместо бездушного номера вы будете видеть на своём телефоне что-то вроде «ООО Стройпоставка» или «Иванов Семён Петрович», получаемые из базы ваших клиентов и контрагентов.
Будет весьма удобно, не правда ли?
А реализуется это очень легко.

Традиционно рассмотрю два варианта — для FreePBX, и для «чистого» Asterisk.

Несмотря на то, что почти повсеместно мы используем доменные имена вместо IP-адресов, инструменты для мониторинга и контроля за сетевым трафиком как правило оперируют IP-адресами. Разрешение имен вообще (и DNS в частности) используется довольно условно.

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

Можно ли иметь актуальную таблицу соответствия имен и адресов для небольших сетей? Какие именно домены запрашивали пользователи и какие получили IP-адреса? С некоторыми оговорками — да.

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

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

Пара примеров:

• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы решили взглянуть на западный опыт и кратко проанализировать тему масштабирования приложений. Нас привлекло руководство Нейта Беркопека (Nate Berkopec), эксперта по Ruby.