Привет, Хабровчане!

В данной статье мы расскажем вам о процессе настройки IPSec VPN на шлюзах Check Point R75.40VS с применением Российских криптоалгоритмов. Данная статья будет интересна в первую очередь инженерам, осуществляющим настройку и поддержку продуктов компании Check Point.

Когда у меня возникла задача настроить на шлюзах Check Point IPSec VPN с использованием российской криптографии, я столкнулся с проблемой нехватки информации, описывающей данный процесс. По данной теме можно найти официальные гайды, описывающие процесс в общих чертах, и немного разрозненной информации в интернете. Лично у меня после их изучения осталось множество вопросов, которые мы постарались осветить в данной статье.

Всё больше и больше организаций выбирают для телефонии не астрономически дорогие, жутко запутанные и ограниченные по функционалу готовые ATC, а современный, расширяемый и абсолютно бесплатный софт, который можно установить на любой дистрибутив Linux. Самым известным и широко распространённым решением для телефонии на базе Linux является, безусловно, Asterisk.

К сожалению для системных администраторов, Asterisk недалеко ушёл от корпоративных АТС в плане простоты настройки. Безусловно, Asterisk может, пожалуй, всё, что только возможно вообразить, но ценой этому является далеко не тривиальная настройка.

У меня за время работы с Asterisk накопилось множество различных примеров конфигурации. Полностью цифровые факсы с возможностью отправки из любого приложения в один клик, интеллектуальная запись звонков, всякие штуки с IVR и т.д. и т.п. Будет заинтересованность — со временем выложу.

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

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

Отправка отчета о пропущенном звонке на email

Что имеем:
Входящая многоканальная линия с номером +7 (495) 1234567, IVR, 4 оператора в очереди вызова.

Задачи:
1. Отправлять отчет о пропущенном звонке, с указанием номера звонящего, времени поступления звонка и времени ожидания на линии.
2. Если абонент ждал на линии более 10 секунд и по какой-либо причине положил трубку, не дождавшись ответа оператора — отправляем отчет о пропущенном звонке.
3. Заносить в БД (в текущем примере MySQL) данные о том, какой оператор в очереди ответил звонок и фиксируем время в которое разговор был завершен.

Определение высоконагруженных систем и способов их построения

      Нагрузка на сервер — это важный показатель использования серверного оборудования. Хит – это запрос клиента к серверу для получения информации. Нагрузка сервера определяется как отношение количества клиентских запросов (хитов) ко времени, выражается в хитах в секунду. Согласно исследованиям Microsoft в 2010 году высоконагруженным сервером можно считать сервер с нагрузкой 100-150 хитов в секунду.
      В литературе встречаются такие понятия как HPC-система, высоконагруженная система, высоконагруженный кластер, Highload-система, суперкомпьютер, которые порой используются как синонимы. Мы будем понимать сайт с нагрузкой не менее 150 хитов в секунду.
      Кластер – это группа компьютеров, которые работают вместе и составляют единый унифицированный вычислительный ресурс. Каждый узел работает под управлением своей копии операционной системы, в качестве которой чаще всего используются Linux и BSD.
      Чтобы понять каким образом задачи, выполняемые кластером, распределяются по его узлам необходимо дать определение масштабироемости. Масштабируемость — способность системы справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов. Система называется масштабируемой, если она способна увеличивать производительность пропорционально дополнительным ресурсам. Масштабируемость можно оценить через отношение прироста производительности системы к приросту используемых ресурсов. Чем ближе это отношение к единице, тем лучше. Также под масштабируемостью понимается возможность наращивания дополнительных ресурсов без структурных изменений центрального узла системы. Масштабирование архитектуры высоконагруженной системы может быть горизонтальным и вертикальным. Вертикальное масштабирование заключается в увеличении производительности системы за счёт увеличения мощности сервера. Главный недостаток вертикального масштабирования в том, что оно ограничено определённым пределом. Параметры железа нельзя увеличивать бесконечно. Однако на самом деле вертикальная компонента присутствует практически всегда, а универсального горизонтального масштабирования как такового не существует. Горизонтальное масштабирование заключается в увеличении производительности системы за счёт подключения дополнительных серверов. Именно горизонтальное масштабирование является сейчас фактически стандартом. Известен также такой термин, как диагональное масштабирование. Оно подразумевает одновременное использование двух подходов.
      И наконец, необходимо определить основной принцип, использующийся при построении любой кластерной архитектуры. Это — трёхзвенная структура системы (рис. 1). Три звена – это фронтэнд, бэкэнд и хранилище данных. Каждое звено выполняет свои функции, отвечает за различные стадии в обработке запросов и по-разному масштабируется. Первоначально запрос приходит на фронтэнд. Фронтэнды отвечают, как правило, за отдачу статических файлов, первичную обработку запроса и передачу его дальше. Второе звено, куда приходит запрос, уже предварительно обработанный фронтэндом — это бэкэнд. Бэкэнд занимается вычислениями. На стороне бэкэнда, как правило, реализуется бизнес-логика проекта. Следующий слой, который вступает в дело обработки запроса – это хранилище данных, которые обрабатываются бэкэндом. Это может быть база данных или файловая система.

В сети любого большого content/eyeball провайдера возникает необходимость управления трафиком. И чем больше сеть, тем острее эта необходимость ощущается. В этой статье я попытаюсь описать основной принцип управления трафиком в сети компании, непосредственное отношение к которой я имею. Сразу оговорюсь, что в этой статье упоминается множество торговых марок, терминов и «жаргона». Здесь не будет ни примеров конфигурации роутеров, ни описания этих самых терминов.

Мы привыкли считать, что транспортная MPLS-сеть необходима, в основном, для applications, которых существует множество: L3VPN, L2VPN/VPLS, и т.д. О Traffic Enigineer'инге в сетях MPLS вспоминают или от «хорошей» жизни, или, скорее, теоретически.

Также принято считать, что backup capacity — это роскошь и, как правило, кариеры/транспортники биллят за backup-порт также, как за обычный. Назревает резонный вопрос: зачем покупать капасити, которые будет просто простаивать и, возможно, несколько раз в месяц на короткое время использоваться? Но, с другой стороны, говорить о том, что «backup'ы для трусов» тоже нельзя, backup'ная емкость должна быть. Как же быть? Об этом и пойдет речь в статье.

Попробуйте сделать traceroute до 216.81.59.173

Получится (с некоторого) момента следующий результат:

Пишу первый пост на данном ресурсе, посему прошу кирпичами сильно не бросать.

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

Как оказалось в JunOS можно сделать это несколькими способами. Т.к. ранее с оборудованием juniper я не сталкивался само собой разумеется был опробовать способ, который советует официальная документация.
www.juniper.net/techpubs/software/junos/junos91/mx-solutions-guide/configuring-basic-mx-series-layer-2-features.html

     В данной статье я опишу, как с помощью родных средств Juniper SRX можно действительно легко и изящно разрулить некоторые раздражающие схемы маршрутизации. Речь пойдет об использовании виртуального маршрутизатора, а точнее, в терминах Джуниперов, routing-instance virtual-router.
     Кратко проблему можно сформулировать так: есть два или больше внешних Интернет-канала (ISP1 и ISP2) и есть веб-сервер внутри сети. На шлюзе поднят source NAT, который отдает страничку обоим внешним интерфейсам. Надо чтобы клиенты обоих провайдеров видели веб-страницу. Проблема в том, что, если, допустим, основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.

     В этой статья я постараюсь максимально доходчиво рассказать о том, как настроить Juniper серии SRX «из коробки». Статья подобного рода уже есть: habrahabr.ru/post/144218, однако моя отличается большей полнотой и подробностью настройки.
     Почему именно Juniper SRX, а не какая-то конкретная модель типа SRX100 или SXR240? Да просто потому что настройки будут полностью идентичными, ввиду полной одинаковости платформы – Junos OS. Это очень удобно, когда вроде бы разные по цене и производительности девайсы настраиваются абсолютно одинаковым образом. В этом лишь одно из достоинств Junos OS.

Целью этой стати является чуть более глубокое чем поверхностное знакомство читателя с относительно новым методом построения VPN-соединений – flex vpn и протоколом согласования ключей IKEv2 как его основы. Здесь я постараюсь рассмотреть преимущества IKEv2 и flex vpn и приведу примеры конфигурирования site-to-site VPN.

Как я писал ранее, мы в своем офисе используем уже около года IP ATC Askozia на базе Asterisk.
Askozia — это коммерческий продукт, цена на который равна стоимости одного IP телефона.

Сегодня я хочу рассказать подробнее о редакторе маршрутов вызовов, который входит в расширенную версию Askozia.
Редактор позволяет создавать неограниченное количество диалпланов Asterisk, используя простой визуальный конструктор. Для построения маршрутов используется более 60 отдельных модулей. Каждый модуль транслируется в одну или несколько команд диалплана Asterisk, а сам маршрут формирует необходимые конфигурационные файлы, которые используются ядром телефонной системы для обработки вызовов.

grep

Многим любителям шела нравится чудная команда grep.
К сожалению, windows нативно не имеет такой команды, по этому некоторые ставят себе наборы различных консольных утилит в *nix стиле, включая grep.

Мне, как любителю посидеть в консоли Windows очень мешало отсутствие грепа, по этому мои скрипты под Win всегда были не так хороши, как могли бы быть. Но мои скрипты должны работать на любой (ну, или почти на любой) Windows, так как же быть?

Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования

Вводные данные

При наличии двух собственных подсетей /24, столкнулся с необходимостью стандартной работы BGP, и погуглив, обнаружил минимальное количество информации по этой теме. На просторах рунета, в основном рассматриваются случаи, когда имеется одна сетка /24, и 2 провайдера, один из которых используется, как резервный. Да даже и этот случай рассмотрен некорректно, либо разрознено, нормально встретил описания только на англоязычных ресурсах.

Сразу же оговорюсь — рассматриваемые фичи CiscoOS: EXIST-MAP и NON-EXIST-MAP не поддерживаются UNIX-аналогами (типа Quagga).

В данной статье я рассмотрю два примера конфигов, исходя из следующих данных.

1. У нас есть два канала: основной рабочий и резервный. Оба провайдера анонсируют нам дефолт. Использование обоих каналов для нас нежелательно. Мы, в свою очередь, будем анонсировать им свои подсети, но если жив основной канал — анонс наших префиксов в резервный канал мы принудительно запретим, и будем анонсировать, только в случае падения рабочего канала
2. У нас есть два рабочих канала. И нам необходимо, чтобы через первый канал всегда работала (анонсировалась) наша первая подсеть, а через второй канал — наша вторая подсеть. Оба провайдера при этом анонсируют нам дефолты. В случае, если падает один из каналов — мы переносим анонс с этого канала, на оставшийся в живых. При возобновлении работы упавшего канала — возвращаем анонсы в начальный вид — по одной подсети через каждого провайдера

Теория:

Привет, Хабрачитатели!

В повседневной практике часто нужен набор инструментов – Linux и иногда Windows LiveCD, а также установочные диски различных дистрибутивов. Диски легко подвергаются механическим повреждениям. Учитывая, что набор используемого инструментария и дистрибутивов у каждого не так велик (во избежания развода зоопарка) и зачастую вполне умещается на USB-носителе до 4G, целесообразно поместить все на одну флэшку.
К вашему вниманию флэшка для загрузки Live сборок Linux и Windows и установки дистрибутивов Linux. Подготовлен образ .img, который легко разворачивается при помощи dd. Кому интересно, подробности под катом.

Имеется один реальный ip (1.1.1.1), три внутренние подсети 192.168.2.0/24 192.168.3.0/24 172.16.0.0/24. Так же имеется дама из бухгалтерии у которой должен работать клиет-банк через наш NAT. SSM-CSC-10 модуль подключен патч-кордом в порт асы f0/3.

Немного про ASA 5510
Основной принцип настройки интерфейсов ASA сводится к назначению security-level от 0 до 100.
0 ставится на незащищённую сеть, как правило внешнюю.
100 ставится на внутреннюю сеть которую нам надо защитить.

Для того чтобы пакет прошел из интерфейса где security-level =0 в интерфейс где security-level =100 нужно создать разрешающее правило в access-list. Нам это понадобиться когда мы будем прокидывать во «внутрь» порт через NAT к нашему клиет-банку в бухгалтерию, а так же для ssh доступа к секурити модулю.

Сразу скажу что у asa 5510 нет своего telnet клиента и это весьма печально. Но выход есть.
Сводится все к тому что в модуле ASA-SSM-CSC-10 стоит наш любимый Linux, поэтому нам надо получить root консоль модуля, а оттуда уже telnet.
Логин пароль по умолчанию на ASA-SSM-CSC-10 модуль cisco Cisco.

• Активируем root аккаунт в модуле
• Заворачиваем NAT-ом tcp порт, например 5555, на ssh порт модуля (В нашем примере у модуля будет ip 192.168.1.1 и порт ssh 22)
• Разрешаем tcp порт 5555 в access-list
• Подключаемся извне по ssh на порт 5555. И вуаля попадаем в bash консоль модуля.
• Дальше заветная команда telnet

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Толчок. За ним ещё один, сильнее. Вот и всё. Перед глазами проносились альпийские луга, и девушка в бежевом сарафане, игриво крутя в точёных ручках кружевной зонтик проносилась мимо тоже. Проносилась, не сбавляя скорости, несмотря на то, что я тянул к ней свои менее точенные, но крепкие ручонки, а также жестами и мимикой изображал, в меру сил своих, какой всесторонний кундюшок её может ожидать, раскинь она мне руки навстречу (ну или ещё что раскинь).
Но случилось что случилось, и лишь ловко выхваченный зонтик из её, кстати, не только точённых но и цепких рук, немного оттенял розовыми тонами последние секунды моего пробуждения и согревал разбитое сердце (без зонтика, закрывающего её шевелюру, девушка оказалась на поверку немного, мягко говоря, плешиватой). Открыв глаза я, как то не странно, увидел себя не посреди развалин Ниигаты, и сразу отринул сейсмическую природу толчков. Немного отлегло. Перестал кричать – «Покинуть корабль!». С укором взглянул на начальника отдела трясущего меня за плечо. Который, вместо извинений принёс мне весть, что нас с ним ожидают у директора, для постановки одного маленького, но очень ответственного задания. Не приняв его слова близко к сердцу, я несколько раз пытался вернуться к своей плешивой искусительнице, но начальник продолжал проявлять чудеса настойчивости. Пришлось идти.

Добрый день, коллеги!

судя по многочисленным вопросам на форуме (ссылка в конце поста), от слушателей и коллег, работа NAT на маршрутизаторах Cisco (firewall'ы я опущу, Fedia достаточно подробно его работу расписал в своей серии статей про Cisco ASA) плохо описана, поэтому я попробую описать свой опыт и свое понимание данной технологии в большинстве ее ипостасей. Не претендую на всеобъемлющее описание и 100% точность, но кому интересно — велкам под кат.

Продолжаем развитие нашей маленькой уютной сети Лифт ми Ап. Мы уже обсудили вопросы маршрутизации и стабильности, и теперь, наконец, выросли для подключения к Интернету. Довольно заточения в рамках нашей корпоративной среды!
Но с развитием появляются и новые проблемы.
Сначала вирус парализовал веб-сервер, потом кто-то притаранил червя, который распространился в сети, заняв часть полосы пропускания. А ещё какой-то злодей повадился подбирать пароли на ssh к серверу.
А представляете, что начнётся, когда мы подключимся к Интернету?!
Итак, сегодня:
1) учимся настраивать различные списки контроля доступа (Access Control List)
2) пытаемся понять разницу между ограничением входящего и исходящего трафика
3) разбираемся с тем, как работает NAT, его плюсы, минусы и возможности
4) на практике организуем подключение к Интернету через NAT и увеличим безопасность сети, используя списки доступа.

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

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