Сетевые технологии *

Пару дней назад мой начальник дал мне задание — пробежаться по всем девайсам в нашей сети и посмотреть каким образом можно улучшить безопасность сети в целом. Я человек далёкий от security, routing&switching — наше всё. Но тем не менее, я взялся за дело. Товарищи по работе подсказали, что стоит погуглить способы защиты management plane (имя в виду, конечно, MPP), я случайно погуглил «MOP cisco» и хорошо, что не сразу понял, что ошибся…

Здравствуйте, разрешите поделиться своим опытом.

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

Каждый, кому приходится заниматься хоть немного IP-сетями представляет основы IP-маршрутизации.
Можно не знать протоколов динамической маршрутизации, или знать, но не до тонкостей. Можно не быть гуру OSPF, BGP и иже с ними, но тот алгоритм, по которому уже из сформированной route-таблицы (сформированной тем или иным способом, вручную или благодаря динамике) выбирается next-hop представляют многие.

Предистория

Рано или поздно системный администратор сталкивается с необходимостью распределить трафик по нескольким каналам, при этом естественно желание чтобы каждый канал использовался по максимуму. Столкнувшись с подобной необходимостью, и решив не изобретать велосипед, обратился к помощи поисковиков. Так как сервер у меня на Ubuntu, то обратил свое внимание на статью http://help.ubuntu.ru/wiki/ip_balancing. Реализовал «Способ 1», но при тесте были замечены следующие критичные проблемы: при использовании ссылок на некоторых сайтах они не открывались (например при попытке включить музыку на ресурсе «ВКонтакте»). Причина очевидна — запрос шел через другой канал. Обдумав ситуацию, решил скомбинировать подход к балансировке. Логика проста — больше всего съедает трафика торренты и им подобные программы, поэтому разделяем трафик. В итоге трафик с портами до 11000 распределяем приблизительно равномерно по количеству абонентов — подсетями, трафиком с портами 11000-60000 выравниваем загрузку каналов.

Изучаю документацию NAS производства NETGEAR. Наткнулся на любопытный документ (внизу страницы). Обратил на себя внимание шрифт — очень мелкий, с рассчетом, что не прочтет никто.

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

Безо всяких вступлений скажу, что устройства на Apple iOS в корпоративных сетях присутствуют в немалом количестве, и в будущем их меньше, похоже, не станет (особенно со столь массовой популяризацией идеологии BYOD). И не важно, используются ли они как непосредственно бизнес-устройства или просто как персональные гаджеты сотрудников и начальства. Поэтому, с ними надо мириться и как-то уживаться. В этой заметке собраны под одной крышей особенности функционирования Wi-Fi в Apple iOS и приведены ссылки на материалы для дальнейшего изучения. Давайте по порядку рассмотрим, что есть и чего нет в iOS, и как с этим жить.

Сеть “Лифт ми Ап” вместе со своим штатом разрастается вдоль и поперёк. Обслуживание ИТ-инфраструктуры вынесли в отдельную специально созданную организацию “Линк ми Ап”.
Буквально на днях были куплены ещё четыре филиала в различных городах и инвесторы открыли для себя новые измерения движения лифтов. А сеть выросла с четырёх маршрутизаторов сразу до десяти. При этом количество подсетей теперь увеличилось с 9 до 20, не считая линков точка-точка между маршрутизаторами. И тут во весь рост встаёт управления всем этим хозяйством. Согласитесь, добавлять на каждом из узлов маршруты во все сети вручную — мало удовольствия.
Ситуация усложняется тем, что сеть в Калининграде уже имеет свою адресацию и на ней запущен протокол динамической маршрутизации EIGRP.
Итак, сегодня:
— Разбираемся с теорией протоколов динамической маршрутизации.
— Внедряем в сеть “Лифт ми Ап” протокол OSPF
— Настраиваем передачу (редистрибуцию) маршрутов между OSPF и EIGRP
— В этом выпуске мы добавляем раздел “Задачи”. Идентифицировать по ходу статьи их будут такие пиктограммы:


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

Довольно много на хабре сказано про интернет-радиовещание изнутри. Есть даже хорошо написанные теоретические основы интернет-радиовещания, с которыми советую ознакомиться. В данной статье я бы хотел рассказать об организации ещё одной любительской интернет-радиостанции, построенной на связке незаслуженно малоизвестного Liquidsoap 1.0.1 и вездесущего IceCast 2.3.2. Статья расчитана на тех, кто хотя бы приблизительно знает, что такое аудиопоток, IceCast, линуксовская консоль и таки что он вообще хочет получить. Однако она и написана начинающим пользователем, поэтому моё решение даже не зарекается на звание оптимального.

На конференции ENOG-4 мое внимание привлек стол, на котором лежали коробочки с наклейкой RIPE NCC, портом RJ-45 и хвостом USB. Вот такие:



Я был не в курсе что это и для чего нужно, по этому подошел и спросил. Оказалось, что это сетевой зонд Atlas RIPE, который можно взять с собой, пройдя регистрацию на atlas.ripe.net. «Надо брать!», подумал я. Ведь нельзя пройти мимо такой милой железочки.

Прежде чем продолжить обсуждение основных черт сетей ZigBee хочу вставить небольшую ремарку.
То, о чем я писал в предыдущем топике и собираюсь продолжить в этом, относится к утвержденному в 2007 году стандарту ZigBee Pro Feature Set 2006. Эта спецификация уже содержит все основные черты, делающие сети ZigBee наиболее предпочтительным вариантом при создании сенсорных сетей различного назначения, а именно:
1) самоорганизация и самовосстановление,
2) структурная гибкость – возможность создания разных по топологии сетей – звезда, дерево, ячеистая (mesh) сеть,
3) возможность выбора алгоритмов маршрутизации, в зависимости от требований приложения,
4) механизм стандартизации приложений – профили приложений, кластеры, конечные точки, привязки,
5) гибкий механизм безопасности,
6) низкое энергопотребление,
7) простота развертывания, обслуживания и модернизации.

Но это не значит, что жизнь остановилась.
Еще в 2008 году, чтобы обеспечить функционирование домовой сети (Home Area Network – HAN) на основе IP альянс ZigBee начал работу над расширением своего стандарта – профилем Smart Energy 2.0. Профиль предполагает поддержку любого транспортного уровня на основе IP-совместимых стандартов, включая ZigBee IP и другие технологии передачи – как радиочастотные, так и по силовой электропроводке – Power Line Carier (PLC).


Профиль обеспечивает взаимодействие между ZigBee и другими сетевыми технологиями. Альянс ZigBee занимается разработкой сетевого уровня Интернет протокола (IP), называемого ZigBee IP и базирующегося на технологии 6LoWPAN (IPv6 по низкоэнергетическим беспроводным персональным сетям). Публичное обсуждение последней рабочей версии (draft 0.9) профиля Smart Energy 2.0 завершилось 25 августа 2012 года. Выход финальной версии ожидается в ближайшее время.
Но уже сейчас выпускается множество сетевых устройств, поддерживающих ZigBee IP, например:


Шлюз ZigBee – Ethernet


Шлюз ZigBee – WiFi – Ethernet


ZigBee – USB Adapter/

В продолжение к посту.
В прошлый раз я рассматривал соединение, когда со стороны циски и микрота были реальные IP'ы.
Здесь рассмотрю пример «серого реальника», т.е серый IP, который провайдер маскирует у себя под внешний с безусловной переадресацией (binat).

Техническая задача: организовать ipip-тоннель между офисами, с шифрованием ipsec, при помощи Mikrotik RB450G и Cisco 2821.

Ньюансы

на циске внешний IP, а на микротике серый, который маскируется провайдером под внешний, с безусловной переадресацией (обращения к этому внешнику из интернета редиректятся на интерфейсный, серый «IP»).
Схема:

Чего «репу» чешешь?
На золотую рыбку другая сеть нужна!

Собственно, я собирался продолжить серию топиков, посвященных работе RTLS – системы позиционирования в реальном времени. А именно, рассказать о беспроводной инфраструктуре системы, основанной на сетях ZigBee. Но вдруг с удивлением обнаружил, что на Хабрахабре нет публикаций, посвященных стандарту IEEE 802.15.4 и спецификации ZigBee. Есть лишь немногочисленные упоминания, связанные с тем или иным приложением. Попытаюсь по мерее сил заполнить этот пробел.

В последнее время все большее распространение и значение приобретают беспроводные сенсорные сети. Сети, которые по своему назначению, параметрам, спецификациям существенно отличаются от сетей связи – WiFi, GSM, LTE и т.п. Среди прочих, используемых в сенсорных сетях, выделяется спецификация ZigBee – наиболее продвинутая надстройка к стандарту IEEE 802.15.4
В этом году исполнилось 10 лет со времени основания ZigBee альянса, а в октябре исполняется 5 лет с момента утверждения действующей в настоящее время спецификации ZigBee Pro Feature Set 2006. Так что публикацию можно считать юбилейной.

Желающих познакомиться с самоорганизующейся самовосстанавливающейся и не требующей специального частотного разрешения сенсорной сетью прошу под кат.

Сразу скажу, чего вы в этой статье не найдете:

• Подробного описания протокола Zigbee
• Подробного описания трансиверов XBee
• Теории и практических рекомендаций по построению mesh drop-in сетей
• Инструкций по работе с Linux
• Инструкций по перепрошивке роутеров и по работе с прошивками от Олега и Open-WRT

Ворнинг для дизайнеров: в посте есть картинка, лучше не смотрите на нее. От необходимости писать подобный ворнинг для программистов я себя избавил, избежав соблазна опубликовать Python-скрипты и thml-код страницы, показанной на картинке (шаблон генерился в Word).

Предполагается, что вы сами-с-усами, способны найти нужную информацию в интернете и обладаете нужными знаниями. Задача статьи – достаточно крупными штрихами описать способ интеграции XBee и Ethernet/Wi-Fi роутера, привести простенький пример работающей системы, указать направления дальнейшего развития.
Поехали.

Я хотел бы рассказать о небольшой доработке системы мониторинга Mikrotik The Dude. Эта система ранее уже упоминалась хабраюзерами gsandul и cedr. Доработку, о которой пойдет речь, я когда-то описывал в своем блоге, но здесь ее сможет увидеть и оценить большее количество народа.

Итак, вкратце: The Dude — довольно мощная и гибкая система мониторинга сетевых устройств, поддерживающая различные типы проверок доступности сервисов и умеющая опрашивать устройства по SNMP. Она поддерживает два типа отправки сообщений о событиях во внешний мир: это e-mail и syslog.

Для оповещения админа по SMS о каких-либо алертах можно пойти традиционным способом — то есть через email-sms шлюз, но в этом случае есть вероятность, что при падении аплинка система до шлюза не достучится и сообщение отправлено не будет. У меня же в наличии были приблудившийся откуда-то 3G модем Huawei E220 от красно-белого оператора, корпоративная симка с условно-безлимитными SMS и собственно сама машина, на которой стояла The Dude — работала она через wine под Ubuntu.

В прошлой статье мы рассмотрели основные моменты настройки сетевого оборудования HUAWEI и остановились на статической маршрутизации. В сегодняшнем топике речь пойдёт о динамической маршрутизации по протоколу OSPF совместно с маршрутизаторами Cisco. Добро пожаловать под кат.

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

Cisco ACS (Access Control Server) — система для централизованной аутентификации, авторизации и аккаутинга пользователей на всякого рода оборудовании, в частности на активном сетевом оборудовании различных производителей.

Имея достаточно небольшой опыт работы системным администратором в крупной компании enterprise сегмента пришёл к выводу, что каждый системный администратор в идеале должен иметь одну учётную запись для авторизации на всех необходимых ему ресурсах: сетевое оборудование, серверы, рабочие станции и т. д. Это связано как с удобством администрирования, так и с безопасностью. В случае увольнения человека можно залочить всего одну учёту в одном хранилище и пропадёт доступ абсолютно ко всему. Но идеальных случаев, как известно, не бывает. В статье мы попробуем приблизиться к идеалу и настроим авторизацию пользователей на активном сетевом оборудовании с использованием учётной записи Active Directory.

Никогда не задумывались, сколько всего приложений написано под андроид?
Системе всего несколько лет, но я никогда и не пытался представить порядок. Пользователей несколько сотен миллионов, а приложений? Десять тысяч? Пятьдесят? Сто?

HUAWEI – одна из крупнейших китайских компаний в сфере телекоммуникаций. Основана в 1988 году.

Компания HUAWEI достаточно недавно вышла на российский рынок сетевого оборудования уровня Enterprise. С учётом тенденции тотальной экономии, на нашем предприятии очень остро встал вопрос о подборе достойной замены оборудованию Cisco.
В статье я попытаюсь рассмотреть базовые аспекты настройки сервисов коммутации и маршрутизации оборудования HUAWEI на примере коммутатора Quidway серии 5300.