Cactus провайдер

Инженеры К12 передают информацию о том, что нашли повреждение кабеля электропитания, через час на месте будет работать аварийная бригада. О сроках устранения аварии и возможности запитать от ДГУ информации пока не поступало. Вот от таких вестей становится сильно легче, понимаешь это просто авария ... просто кабеля...

Какая-то авария на К12 в Петербурге, разные проблеммы у разных операторов. Более информации пока нет. У нас овалился канал связи с Янино. Остальное пока на плаву.

Королевский сервис на линии связи: как наши монтажники спасали Ее Величество. При осмотре линии связи монтажники обнаружили в коробке застрявшее насекомое. Думали шершень, но оказалось — королевская особа, крупная матка осы, которая решила перезимовать в оптике. Как приличествует королеве — своего она не упустит, зажала волокно намертво. Чтобы вызволить заложницу собственного великодержавного Эго без травм, парням пришлось перекусить зажатое оптическое волокно. Гостью бережно пересадили в безопасное место, а волокно переварили. Вот она — королевская забота о клиентах и окружающей среде от нашей команды! Интернет работает, королева в безопасности. 🤍

Восстановили магистральный канал Мурино-Петербург после повреждения. Работаем как обычно в режиме полного резервирования. 🛠 Хорошая практика — нагружать каналы связи не более чем на половину, и при этом каждый канал даже в одиночку должен выдерживать всю нагрузку. Выходит что нагрузка в четверть от емкости обеспечивает свободу маневра в любой ситуации. Интернет при аварии не отключался, но инцидент помог нам устранить недочет в работе ТВ при обрыве магистралей. Теперь наш отечественный коммутатор Eltex MES5324 самостоятельно принимает ТВ-потоки по протоколу PIM от поставщика технического ТВ сигнала Глобалнет на точке обмена трафиком Большая Морская, 18. Второй поставщик сигнала — Инетком — подает нам сигнал на другой точке обмена (К12). Мы рассчитываем, что благодаря такой схеме оба источника ТВ-сигнала будут полностью доступны при подобных авариях в дальнейшем. Оставайтесь на связи! 🚀

Все сервисы полностью восстановлены в полном объеме, к сожалению, пришлось поработать ручками, отключение произошло в час максимальной нагрузки, и автоматическое переключение пустило огромный трафик не оптимально. Как же здорово, что есть альтернативные каналы связи :) Оставайтесь на связи!

Скорее всего обрыв кабеля на Высоковольтной ЛЭП. На Дальнем Востоке сегодня, так вообще была попытка связь положить полностью - https://t.me/Telecomreview/14639 , а у нас скорее всего ветер.

Инет полностью в строю, ТВ пока подправляем.

Авария 100G канала в неприятном месте, меняем конфигурацию сети, скоро все нормализуем. Пока Инет тормозит, но уже отпускает.

🌐 Шутки в сторону: серьезный телеком Крупные клиенты — банки, сетевые магазины или госорганы — часто уже имеют своих федеральных поставщиков телеком-решений. Им так удобнее. Но тянуть свои физические кабели к каждой региональной точке накладно. «Кактус», как надежный оператор, предоставляет такие каналы («последние мили») широкому спектру других операторов. Многие наши партнеры знают, как серьезно мы работаем, и берут у нас десятки услуг связи. Наша задача — сделать такие услуги железобетонными. Обычно подобные задачи обеспечиваются арендой виртуального канала связи — VLAN. Это классическая технология, которая позволяет через любую L2-сеть «просверлить» независимый канал. Традиционно для этого цепочка VLAN прописывается вручную на каждом коммутаторе в сети от точки стыка с партнером до конечного клиента. 🚜 Но трактору не объяснишь... ...всей важности того, чтобы у поликлиники или отделения банка оставался доступ в государственную базу данных. К сожалению, магистральные кабели рвутся. А городить резервные кольца (STP/ERPS) внутри клиентских виланов — дело сомнительное. Внутреннее пространство клиента — его святая территория, там должны бегать только его данные, и наши протоколы резервирования не должны туда вмешиваться. Вы порой, наверное, замечали, что мы пишем в канале о проблемах с обрывами магистралей, а сервисы у клиентов работают как прежде. Рассказываем секреты. Один из наших секретов — технология VXLAN (Virtual Extensible LAN), которую мы научились использовать в мультивендорной среде. Мы упаковываем клиентский L2-трафик в IP-пакеты и пускаем по опорной сети. Если падает одна магистраль, наша сеть за доли секунды перенаправляет IP-пакеты по резервному маршруту. Клиент внутри своего VLAN даже не замечает аварии. 🦄 Суровая reality мультивендора (о чем молчат в рекламе) К сожалению, на фоне хвалебных маркетинговых статей вендоры забывают упомянуть важную деталь. Разработчики аппаратных чипов (ASIC) для VXLAN, видимо, живут в стране розовых пони. Они решили: раз пришел VXLAN, значит классическим VLAN в сети больше не место. Поэтому «из коробки» на свитчах VXLAN аппаратно заводится нормально только поверх чистых routed IP-интерфейсов — без транков и виланов под ними. Очень неприятная история. Как это обходится на практике? На Cisco Nexus решается, явно указывая виланы, поверх которых разрешено гонять L3 UDP-трафик инкапсуляции: system nve infra-vlans 2200,2209... На коммутаторах MikroTik (CRS серии) аппаратный чип так делать просто не умеет — там VXLAN поверх транка нативно не полетит, точнее у нас удавалось это запускать, но до первой перезагрузки. Но и это еще не всё. Ловите настоящий эксклюзив: популярные коммутаторы серии Cisco Nexus 93180YC-EX имеют аппаратное ограничение чипа Cisco Cloud Scale ASIC. Он не умеет обрабатывать чистый MPLS внутри VXLAN на уровне железа и просто дропает такие пакеты. Чтобы обойти эту проблему и пробросить такой трафик, его приходится дополнительно оборачивать в GRE-туннели. В чем же наш секрет успеха? Когда задача локальная — мы приземляем этот трафик на производительных маршрутизаторах MikroTik серии CCR, где VXLAN обрабатывается программно (на CPU). Но если нам самим нужно принять многогигабитный поток Интернета с удаленной точки обмена трафиком под полноценный BGP, мы идем еще дальше — в сторону Debian Linux. Процессоры этих платформ и современных сетевых карт перемалывают сложную инкапсуляцию настолько быстро и без ограничений железных чипов, что мультивендорный стык работает идеально на любых скоростях и с любыми типами вложенного трафика. 🛠 Показываем конфиги на примере двух разных задач Задача №1: Высокоскоростной BGP-стык для собственных нужд (VLAN 1735) Когда нам нужно принять высокоскоростной поток трафика на наш BGP-маршрутизатор на базе Debian Linux, мы заводим его в отдельный VLAN 1735 и упаковываем в туннель с VNI 1001735. 1. На стороне Cisco Nexus 9000 (Точка К12): text

! Обход аппаратного ограничения на Nexus
system nve infra-vlans 2200,2209,2216,2220,2231,2260

!связь держим строго через loopback интерфейсы, адреса которых анонсируем в OSPF
interface loopback0
  ip address 172.16.16.100/32

! Связка нашего BGP-вилана и VXLAN ID
vlan 1735
  vn-segment 1001735

interface nve1
  no shutdown
  source-interface loopback0
  member vni 1001735
    ingress-replication protocol static
      peer-ip 172.16.16.3

2. На стороне Debian Linux (Наш пограничный BGP-маршрутизатор /etc/network/interfaces): Туннель поднимется прямо на лету, принимает «белую» подсеть и готов молотить многогигабитный трафик: text

auto vx1735
iface vx1735 inet static
    pre-up ip link add vx1735 type vxlan id 1001735 local 172.16.16.3 remote 172.16.16.100 dstport 4789 || true
    up ip link set vx1735 up
    down ip link set vx1735 down
    post-down ip link del vx1735 || true
    
    # Публичная IP-сеть для BGP-сессии (данные изменены для безопасности)
    address 198.51.100.22
    netmask 255.255.252.0
    network 198.51.100.0
    broadcast 198.51.103.255
    hwaddress ether 02:47:29:78:37:44 # Точка обмена К12
    mtu 1500

Задача №2: Аренда изолированного L2-канала для клиента (VLAN 3448) Если же речь идет о транзитном B2B-канале для партнера, трафик летит с Nexus через тот же VXLAN-транспорт, но приземляется на MikroTik CCR для дальнейшей прозрачной передачи. На стороне MikroTik CCR (Прием клиентского туннеля):

# Создаем VXLAN туннель для клиента
/interface vxlan
add bridge=bridge-switch bridge-pvid=3448 local-address=172.16.16.19 name=vxlan-3448 vni=1003448

# Пробрасываем VLAN 3448 внутри бриджа роутера, принимаем из vxLan и отправляем в SfpPlus11
/interface bridge vlan
add bridge=bridge-switch tagged=sfp-sfpplus11,bridge-switch,vxlan-3448 vlan-ids=3448

Итог: Мы нашли способ объединить сильные стороны совершенно разных платформ — от enterprise-железа Cisco до гибкого Linux и популярных MikroTik. Мы успешно обходим их аппаратные «болячки», строим скоростные стыки и даем партнерам изолированные, защищенные от аварий каналы связи. Сеть работает стабильно, а инженеры спят спокойно. Оставайтесь на связи! 🌵

Cвязистов сегодня собрали на совещание в связи с уязвимостями в оборудовании Микротик, в ходе возник вопрос о том, а как проверить на уязвимости тысячи устройств клиентов. Я предложил использовать LDP и CDP протоколы в которых микротики активно показывают свою версию ПО. Но у коллег была сеть VLAN на клиента и к каждому не заглянешь с таким протоколом. В итоге сейчас сел, подумал и родилось изящное решение в рамках закона. 🛠 Шаг 1. Быстрый тест в ручном режиме Для начала подготовим окружение и проверим один тестовый роутер. Ставим сканер Nmap:

apt install nmap

Скачиваем специализированный NSE-скрипт: wget https://svn.nmap.org/nmap/scripts/mikrotik-routeros-version.nse Запускаем точечную проверку тестового роутера:

nmap -p 8291 --script mikrotik-routeros-version 172.16.16.19

Что мы получаем в выводе?

PORT     STATE SERVICE
8291/tcp open  winbox
| mikrotik-routeros-version:
|   list:
| wave2.jg    7.20.5
| secure.jg   7.20.5
|_roteros.jg  7.20.5
Service Info: OS: RouterOS 7.20.5; CPE: cpe:/o:mikrotik:routeros:7.20.5

Скрипт напрямую обращается к WinBox и вытаскивает точную версию OS (в данном примере 7.20.5) и список всех активных пакетов. 🚀 Шаг 2. Масштабируем на всю сеть (Автоматизация) Чтобы не сканировать каждый IP руками, заворачиваем процесс в быстрый Bash-скрипт cactus_micro_scan. Он умеет работать на больших скоростях, не зависает на "мертвых" хостах благодаря таймаутам и показывает индикатор прогресса. Создаем файл subnets.txt и закидываем туда списки нужных подсетей (каждая с новой строки):

172.16.16.0/24
192.168.1.0/24

Запускаем наш инструмент (предварительно дав ему права на запуск через chmod +x):

./cactus_micro_scan

Как это выглядит в консоли:

[DEBUG] Загружено целей для сканирования: 2
[+] Начинаем ускоренное сканирование...
[1/2] Проверяем: 172.16.16.0/24 ... [/] Готово
[2/2] Проверяем: 192.168.1.0/24 ... [-] 
[!] Обнаружен уязвимый хост: 192.168.1.55 (7.20.5)
Готово

📋 Результат На выходе скрипт генерирует чистый текстовый отчет в файле vulnerable_mikrotiks.txt, куда заносит только те IP-адреса, на которых крутятся потенциально опасные и устаревшие версии RouterOS. Скрипт добавил к сообщению, добавьте ему права на выполнение.

С Днём рождения, Новое Девяткино! 🎁 Дарим домашний кинотеатр нашим абонентам! Друзья, сегодня наш общий праздник. Именно в Новом Девяткино 25 лет назад начиналась история нашей сети. В то время в посёлке вообще не было Интернета. Я обзвонил всех крупных провайдеров, везде получил отказы и решил: «А сделаем всё сами!». Спасибо, что все эти годы вы остаётесь с нами. В честь юбилея мы приготовили для вас крутой подарок — бесплатный доступ к новому медиасерверу с тысячами фильмов и сериалов в отличном качестве! 🎬 Как запустить кино у себя дома: • На компьютере или смартфоне: просто перейдите по ссылке и зарегистрируйтесь за 1 минуту ➔ https://kinoplus.net/jfa/invite/eFTxjzvfrwdAf8JkhDCbXa • На телевизоре (Smart TV, Android TV, Яндекс.СтанцияТВ или даже Xbox): скачайте бесплатное приложение Jellyfin ➔ jellyfin.org и войдите под своими данными после регистрации, указав адрес сервера https://kinoplus.net ⚠️ Обратите внимание: Доступ работает внутри нашей домашней сети. Используются мощные европейские серверы, и сейчас завершается отладка нового софта. и железа. Количество приглашений ограничено! Успейте зарегистрироваться и занять своё место, пока идёт закрытое тестирование. Приятного просмотра, отличных выходных и с праздником! 🎆

⚡️ Уважаемые жулики! Рубрика «Занимательная физика» Доводим до вашего сведения: воровать нулевой проводник (ноль) в жилом доме — гораздо опаснее для жизни, чем срезать обычный фазный кабель. Стоит вам перерезать ноль, как этот кусок провода мгновенно превращается в ловушку с высоким напряжением. В голове среднестатистического прохиндея это обычно не укладывается, поэтому объясняем на пальцах. Любой домашний чайник — это просто кусок хитрой термостойкой проволоки. И если в момент кражи тётя Маша решит попить чайку, она сама того не ведая устроит вам засаду. Её чайник напрямую соединит отрезанный вами ноль с её фазой. Но это полбеды. В это же время в соседнем подъезде дядя Саша решит пожарить колбасу на электроплите. А у Маши и Саши фазы, как водится, разные. Без общего нуля в общедомовую сеть мгновенно ворвутся 380 Вольт вместо привычных 220! И ладно бы этот мощный разряд достался только вам — мы бы погоревали и забыли. Но эти 380 Вольт пойдут гулять по розеткам всего дома. У тёти Наташи сгорит холодильник, у соседа Игоря — дорогой компьютер, а у нас, провайдера «Кактус» — коммутаторы. 🛑 Дорогой жулик! Если после этого вас найдут разгневанные жильцы, поверьте: удар током покажется вам самым мягким и приятным финалом этого вечера. Подумайте об этом. Не надо воровать кабель, если вы так их любите, лучше идите их прокладывать, монтажники отлично зарабатывают и спят с чистой совестью. 💡 Важная информация для абонентов и жильцов: Если у вас дома внезапно начали неестественно ярко гореть или моргать лампочки, зашумел холодильник или задымился телевизор — немедленно полностью обесточьте квартиру через входной щиток (автоматы)! Скорее всего, в доме произошло «отгорание нуля». После этого сразу вызывайте аварийную службу вашей управляющей компании. Гарантированно именно эту проблему решает реле напряжения на входе в квартиру. По мотивам вчерашних событий в Мурино.

Центральная серверная без света в доме ведутся работы, ждем когда вернется. Из-за того, что кабельная ТВ сеть - это дерево с корнем в этой серверной оно пока лежит. IPTV и Интернет работают, не замечая проблему.

По направлению на Piter-IX с утра сработал алерт - обнаружена закольцовка, и коммутатор автоматически погасил порт избегая возможных больших неприятностей. Вечером подтормаживает инет, и не понимаем а что такое, ощущение не хватает внешней полосы, и точно! Исправили в 21-15. Подправили мониторинг на случай такой неожиданности.

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

🍿 Из нашей сети есть доступ к легендарному шведскому серверу — https://sosis.co. И прямо сейчас он переезжает на современную платформу! Главная задача — обеспечить стриминг контента в самом доступном формате. На сегодня золотой стандарт — это контейнер MP4, кодек H.264, звук AAC. И никакого лишнего мусора внутри: удаляем встроенные картинки, тяжелые метаданные, шрифты и хитрые субтитры, которые вешают плееры. 📐 Масштаб задачи огромный: нужно проинспектировать и перекодировать десятки терабайт видео. В ход пошел мощный комбайн Tdarr. Он собирает распределенную сеть из отдельных серверов-нод с десятками ядер CPU и видеокартами NVIDIA. Готового плагина под наши задачи не нашлось — вся индустрия сейчас помешана на HEVC (H.265). Пришлось написать плагин, ведь у старых телевизоров от рассказов про крутизну новых кодеков аппаратный декодер сам не вырастет. 💡 Из необычного, что всплыло в ходе работ: Если взять старый файл (например, в DivX) и перекодировать его в H.264 или H.265, то итоговый размер файла... может стать больше исходника! Знаете почему? В старых «ламповых» фильмах алгоритмы сжатия были несовершенными. Из-за этого видео забито микро-артефактами и шумами, незаметными для глаза. А современный умный кодек честно пытается сохранить каждую эту детальку, что в итоге раздувает битрейт и размер. Кстати, пока тестировали сеть, с удовольствием пересмотрел фильм «Майкл» (тот самый, где Траволта играет неидеального ангела) в старом формате и с той самой культовой озвучкой из 90-х. Есть в этом кино что-то невероятно человеческое. В общем, работа кипит. Ждите анонсов и готовьте попкорн! 🎬

🚀 Безопасность MikroTik: почему нас не пугают «шокирующие истории» об уязвимостях Мы используем MikroTik. Это недорогое и заточенное под специфические задачи оборудование. Например, MikroTik CCR2004-1G-12S+2XS отлично справляется с тем, чтобы по 10G подключить несколько многоквартирных домов к сети и отправить их данные в центр на 25G. И вот почему громкие новости о взломах нас скорее всего не заденут — дело в правильной архитектуре и настройках. 🛡 Наш главный принцип Зная о проблемах с безопасностью, которые рано или поздно касаются любого ПО, мы изначально строим сеть правильно: 1. Минимум белых IP: Мы стараемся не вешать на само оборудование реальные IP-адреса, если это возможно. 2. Изоляция: Сегмент управления (Management) полностью закрыт от доступа со стороны пользователей и Интернета. Именно поэтому мы так легко делимся скриншотами и фото с внутренними IP-адресами устройств. ⚙️ Базовый конфиг файрвола на MikroTik При начальной настройке мы жестко ограничиваем доступ к самому роутеру. Шаг 1. Создаем список доверенных адресов (Address List) Создаем лист с именем man, где перечислены IP-адреса и подсети, откуда админам разрешен доступ. Выполняем в консоли для каждой админской подсети: /ip firewall address-list add address=1.2.3.0/24 list=man Шаг 2. Защищаем сам роутер (Цепочка INPUT) Важно: все правила ниже действуют только на запросы к самому устройству и не трогают транзитный трафик пользователей. 1️⃣ Разрешаем уже установленные соединения (чтобы роутер мог сам скачивать обновления, синхронизировать время и отвечать на ваши запросы): /ip firewall filter add action=accept chain=input connection-state=established,related 2️⃣ Блокируем сомнительные коннекты (например, полуоткрытые или ошибочные пакеты): /ip firewall filter add action=drop chain=input connection-state=invalid 3️⃣ Разрешаем доступ админам из списка man: /ip firewall filter add action=accept chain=input src-address-list=man 4️⃣ Разрешаем пинговать роутер (полезно для мониторинга): /ip firewall filter add action=accept chain=input protocol=icmp icmp-options=8:0 5️⃣ Разрешаем некоторые варианты traceroute (например с Linux/macOS): /ip firewall filter add action=reject chain=input protocol=udp dst-port=33434-33523 reject-with=icmp-port-unreachable Шаг 3. Финальная блокировка (ВНИМАНИЕ!) Прежде чем вводить запрещающее правило, убедитесь, что в первых правилах в Winbox (IP -> Firewall) побежали счетчики пакетов (статистика). Если все ок, включаем тестовый режим через LOG: /ip firewall filter add action=log chain=input log-prefix="DROP_INPUT: " Смотрим в логи. Если там нет ваших админских пакетов — все настроено верно. Теперь можно смело менять в Winbox действие с log на drop. Либо сразу ввести финальную команду (если уверены в себе): /ip firewall filter add action=drop chain=input С этого момента подключиться к любым сервисам MikroTik (Winbox, SSH, Web) смогут только те, кто находится в списке man. ⚠️ Важное примечание: Если этот роутер общается с другими устройствами по протоколам OSPF, BGP, VRRP или работает как VPN-сервер, эти протоколы нужно отдельно разрешить в файрволе (выше запрещающего правила). Ну, или просто добавьте IP-адреса соседних роутеров в ваш список man, если и соседние устройства полностью внутри защищенного периметра. 🔥 Очень важный нюанс про Winbox! Роутер обрабатывает правила файрвола строго сверху вниз до первого срабатывания. Любое новое созданное правило автоматически падает в самый конец списка. Поэтому, если вы добавите новое разрешающее правило после нашего финального DROP, оно просто не будет работать. А перетаскивать нужные правила можно мышкой, тем самым меняя их порядок!