Записи с меткой «Networks»

Всем привет. Сегодня я немного поделюсь впечатлениями от мощных точек доступа WiFi отечественного производителя — компании Eltex.
У них много всякого железа, и первый раз я познакомился с их продукцией на примере Voip-шлюзов и свитчей доступа MES, оставшись ими более чем доволен.
Если вам интересно про их беспроводные железяки — лезем под кат.
(далее…)

Есть в линуксе такой очень тёплый и очень ламповый файервол — iptables.
Присутствует он там уже 20 с лишним лет, и чаще всего используется либо в настройках по умолчанию, либо для классической раздачи инета через шлюзовой сервер посредством NAT/MASQUERADE. Иногда про него вспоминают, если поднятый сервис после старта оказался не доступен из инета =)

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

IPSET.

Офигенная штука, когда надо работать с крупными списками адресов или список адресов должен быть использован более одного раза.
Пример — есть у нас список IP адресов (ркн, телеметрия майкрософт, копирасты, спамеры и прочие злыдни), с которыми соединяться не нужно даже случайно ни на вход, ни на выход. Список при этом может часто меняться. Размещать всю эту муру в основном конфиге файервола — сложно, неудобно и чревато поломкой сети в случае ошибки.
Что мы делаем ? Ставим пакет ipset, и пишем простейший скрипт типа такого:

#!/bin/sh

ipset -N banlist iphash
ipset -F banlist

# Spam bots
ipset -A banlist 92.127.233.224
ipset -A banlist 208.103.122.165
...
ipset -A banlist 95.101.95.129/25

А в начало конфига файервола пишем вот такое:
-A INPUT -m set --set banlist src -j DROP
-A OUTPUT -m set --set banlist dst -j DROP

Всё, любой входящий траффик с этих адресов и исходящий на них же будет дропаться с регистрацией в соответствующих счётчиках (iptables —list -vn). Важных замечаний ровно два. Первое — ипсеты использует такая лютая надстройка, как firewalld. Мне не очень нравится его развесистая лапша из таблиц, пытающаяся описать все распространённые случаи. Надо внимательно смотреть, что ипсеты правильно применились. Зато он полностью сам рулит ипсетами, правилами, последовательностью запуска и прочим. Но конфиг на выходе — в три экрана. Впрочем, ничто не мешает снести надстройку и написать свой конфиг файервола со скриптами, сетами и логгерами.
Второе — сеты должны быть созданы ДО запуска файервола. Как именно вы это сделаете — через юниты systemd, скриптами из rc.local или ещё как — не суть. Главное — конфиг с -m set сработает только тогда, когда используемый ipset будет создан (вполне может быть и пустым).

Очень полезная особенность — правка ipset-ов не рестартит файервол, не сбрасывает его счётчики, не трогает никакие другие правила, к ipset-у не относящиеся. В простых конфигах ipset может показаться лишней сущностью. Но для систем типа fail2ban или случая развесистых списков адресов для правил — вещь незаменимая.

-m owner

Ещё одна редко используемая, но тоже в ряде случаев полезная опция.
Идея в том, что ядро системы знает, какой исходящий траффик процессом какого пользователя порожден, и может на основании этого применить специфичную обработку траффика.
Вспомнил я про это, когда один из моих знакомых спросил, можно ли запустить некое виндовс-приложение в WINE так, чтобы он не могло вылезти в сеть.

В этом случае самое очевидное, и при этом весьма надёжное — отдельная виртуальная машина. Но это а) куда менее удобно б) требует ещё один инстанс ОС.
Однако есть и готовое решение, изумительно простое в своей изящности. Оно не столь надёжно, как изолированная ВМ без сетевой карты, но поставленную задачу тоже решает.
Идея в том, что iptables для исходящего траффика может различать траффик не только по пользователю, но и по его группе и даже по SELinux-контексту. Возня с отдельными пользователями под каждую софтину — неудобна и проблемна из-за прав доступа и вопросов доступа к X-серверу, SELinux сам по себе та ещё черная магия, а вот доступ на основе группы — это то, что доктор прописал.

Базовый ман для убунты на английскои тут: https://askubuntu.com/questions/249826/how-to-disable-internet-connection-for-a-single-process/393013#393013

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

groupadd no-internet

Дальше делаем нашего пользователя членом этой группы:
usermod -G no-internet UserVasya
ВАЖНО !! Опция -G — заглавной буквой ! То есть мы добавляем пользователя UserVasya в группу no-internet, но ОСНОВНУЮ группу пользователя не меняем ! Если перепутать — пользователь останется с отломанным инетом.

В файлах это будет выглядеть вот так:

# cat /etc/group | grep UserVasya
UserVasya:x:1000:
no-internet:x:1011:UserVasya

# cat /etc/passwd | grep UserVasya
UserVasya:x:1000:1000:UserVasya:/home/UserVasya:/bin/bash

Тут у нас есть пользователь UserVasya c UID = 1000, его основная группа — тоже UserVasya, с GID = 1000. Но он также входит в группу no-internet c GID = 1011. Именно это членство позволит пользователю менять группу без ухищрений с судо и запросов паролей.

Теперь напишем сетевое правило для этой группы где-нибудь в начале фильтров для OUTPUT:

-A OUTPUT -m owner --gid-owner no-internet -j DROP

Тут мы говорим файерволу, что траффик, порожденный процессами c группой no-internet, надо тихо дропнуть.

А дальше мы просто воспользуемся утилитой sg (substitute group).

Примеры волшебных команд:

sg no-internet quake2
sg no-internet konsole
sg no-internet ~/.wine_radmin/radmin.sh
env WINEPREFIX=/home/user/.wine_ut2004 sg no-internet 'wine "C:\UT2004\System\UT2004.exe"'

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

Однако это не является 100% способом !
Например, запущенный таким образом firefox группу не меняет, и остается с сетевым доступом !

Так что реально критичным сервисам — своя ВМ, со своим файерволом.

В следующий раз попрактикуемся в ч0рной магии.

срамосорм

Posted: 2019-08-29 in IT
Метки:

То, что рано или поздно должно было случиться, случилось.

На CC’2019 в одном докладе добрым человеком была раскрыта одна утечка данных из системы СОРМ. Сам дамп хоть и весьма отрывочен и криво распарсен, крайне интересен для изучения.

Помимо ошмётков http-траффика на 443-м порту, там есть ещё масса примеров работы шпионских мобилко-бэкдоров, траффик китайских троянов, и прочий занятный цифровой мусор. Слив номеров IMEI, версий софта, номеров телефонов тоже есть.

А вам правда всё ещё нечего скрывать ?

Заметка будет про китайское железо с бэкдорами и сетевую магию для нейтрализации подобной муйни.
(далее…)

в сети штормило …

Posted: 2019-02-13 in IT, Networks
Метки:,

Иногда некоторые сервисы, использующие мультикаст, могут порождать массовую генерацию мультикаст-траффика.

мультикастовый шторм 2gbps

Вот эти два пика — случившийся в одном из сегментов сети мультикаст-шторм мощностью примерно в 1,5 — 2 гбит/сек, предположительно порожденный сглючившими процессами corosync. От такой херни весь сегмент сети начинает очень сурово колбасить, потери пакетов достигают 80%, любое сетевое взаимодействие становится крайне медленным и нестабильным, всё становится очень нехорошо.
Чтобы такой херни не происходило, необходимо включать такую вещь, как Storm Control.

На джунипере оно для мультикаста по умолчанию _выключено_.
Конфигурим:

Amin@EX3300> show configuration ethernet-switching-options storm-control
interface xe-0/1/0.0 {
bandwidth 65536;
multicast;
}
interface all {
bandwidth 16384;
multicast;
}

Можно задать максимально допустимое количество принимаемого в порт широковещательного траффика как в процентах от толщины канала (level), так и в абсолютных значениях (bandwidth), в килобитах/сек. Задаваемые значения зависят от используемых приложений, в штатном режиме в логах не должно быть ругани на срабатывание storm control.

Пара подводных камней:
1). Есть ELS и не-ELS версии. Для els версий настройка немного иная (forwarding-options storm-control-profiles):
https://www.juniper.net/documentation/en_US/junos/topics/example/rate-limiting-storm-control-configuring-els.html

2). Для broadcast и unknown-unicast траффика ограничения storm control могут применяться по умолчанию, но им может быть разрешено съедать до 80% полосы.

Такая простая настройка дополнительно убережёт вашу сеть от опасно сглючивших девайсов.

i2p

Posted: 2018-12-11 in IT
Метки:,

Вошел в довольно стабильное состояние и выпускается нормальными пакетами i2pd:

https://github.com/PurpleI2P/i2pd/releases

Он существенно легковеснее классической джава-софтины.

Веб-морда тоже существенно проще и легче. В отдельной ВМ попробовать рекомендую я.

1Gbps WAN UP !!

Posted: 2018-12-08 in IT, Networks
Метки:

Апгрейд может затрагивать не только железо и софт, но и каналы связи. Мой домашний инет был подключен более 10 лет назад, и протянут был 4-х жильным кабелем. Но прогресс не стоит на месте, буквально сегодня кабель заменили и я узрел новые горизонты радости :

(далее…)

Надо быстро слить крупный дамп неприватных данных.
В текущем каталоге запускаем такое:

python -m SimpleHTTPServer

И на 8000-м порту видим веб-сервер с индексом каталога. По завершении стопаем этот «фемтосервер :D» по Ctrl-C.
Это изумительно и прекрасно. Само собой, ценные базы и чувствительные данные так перекидывать не надо, для ценных данных есть SSH.

В порыве борьбы с телегой ркн слетел с катушек и начал применять массовые баны подсетей:

cat dump.xml | grep ipSubnet
68.171.224.0/19
74.82.64.0/19
103.246.200.0/22
178.239.88.0/21
203.104.152.0/22
203.104.144.0/21
203.104.128.0/20
91.108.4.0/22
91.108.8.0/22
91.108.12.0/22
91.108.16.0/22
91.108.56.0/22
149.154.160.0/22
149.154.164.0/22
149.154.168.0/22
149.154.172.0/22
52.56.0.0/16
18.130.0.0/16
13.125.0.0/16
52.57.0.0/16
35.180.0.0/16
18.144.0.0/16
52.32.0.0/16
18.218.0.0/16
52.58.0.0/15
18.196.0.0/15
18.194.0.0/15
18.184.0.0/15
54.228.0.0/15
35.178.0.0/15
18.236.0.0/15
54.212.0.0/15
13.230.0.0/15
35.176.0.0/15
35.156.0.0/14
13.56.0.0/14
18.204.0.0/14
35.160.0.0/13
34.248.0.0/13
34.240.0.0/13
54.64.0.0/13
54.160.0.0/12
54.144.0.0/12
52.64.0.0/12
52.192.0.0/11
34.192.0.0/10
109.239.140.0/24
23.251.128.0/19
139.59.0.0/16
35.184.0.0/13
35.192.0.0/12
35.224.0.0/12
35.208.0.0/12
174.138.0.0/17
188.166.0.0/17
46.101.128.0/17
167.99.0.0/16
206.189.0.0/16
159.89.0.0/16
165.227.0.0/16
159.203.0.0/16
128.199.0.0/16
159.65.0.0/16
51.136.0.0/15
195.154.0.0/17
51.15.0.0/16
185.166.212.0/23
178.63.0.0/16
91.121.0.0/16
64.137.0.0/17
47.91.64.0/19
94.177.224.0/21
159.122.128.0/18
174.104.0.0/15
98.158.176.0/20
176.67.169.0/24
185.229.227.0/24
45.76.82.0/23

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

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

Всем привет !
Я очень давно хотел поразбираться с двойным тегированием на домашнем роутере Juniper MX-серий, и вот этот момент настал. В отличие от EX, где настройки QinQ относительно немногочисленны, МХ-серия обладает просто огромным количеством настроек свитчинга, а поддержка виртуализованных инстансов и целой пачки технологий позволяет городить очень сложные конфигурации.
Задача этой заметки — разобрать средствами самого МХ-80 дважды тегированный траффик, пришедший в общем аплинке вместе с другими одиночно тегированными вланами и нетегированным траффиком, и после снятия верхнего тега сбриджить эти вланы с уже существующими вланами на МХ. Не забыть про native само собой. Если интересно — просим под кат.
(далее…)

В камерах и DVR (IP-видеорегистраторы) hikvision похоже нашли новую багу. Пару лет назад я уже писал очень матерно-ругательную статью про эти железки, но сейчас проблема приобрела серьёзный размах — наблюдались массовые взломы таких систем, сброс настроек (даже при сильных паролях), DDoS-атаки с них (DNS-/NTP-усиление) и использование хакнутого оборудования для атак на другие сети / подбор паролей к сервисам (telnet, ssh, vnc, rdp — точно) и прочему непотребству.

Что интересно, бевардовские камеры и даже длинки, висевшие в тех же сетях, не постарадали, так что проблема чисто хиквижена. Всем срочно патчиться, менять пароли, по возможно выносить IP-камеры в более защищённые сегменты сети.

Если вам нужно повесить камеру на внешний адрес, то НЕ НАДО прифигачивать её сразу внешний адрес напрямую — ни в IPv4, ни в IPv6. Если есть роутер — затащите её за этот роутер и сделайте Port-forward для RTSP вида :

TCP+UDP: xy554 --> 192.168.x.y:554

Для получения видеопотока этого более чем достаточно. Если камера оказалась единственной на объекте (бывает такое) — применить IP-whitelist. Правда если этот вайтлист на камере обслуживает только веб-доступ, но не применяется для доступа по телнет/ссш (да, вам не приглючилось, телнет там живее всех живых и доступен на куче девайсов через интернеты) или иному кривому порту — то может не помочь.

Так что в случае хиквижена — именно big, именно факинг и именно фейл, и именно с секурити.

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

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

Если вам интересно — вэлкам, постараюсь рассказать о том, как появились такие системы, какие бывают и что вообще там интересного.
(далее…)

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

На этот раз снова госдеп, а если точнее — коварные агенты ЦРУ.
викиликс как раньше аццки жгла, так и продолжает жечь сейчас.
Встречаем: http://nag.ru/news/newsline/31897/tsru-bolee-desyati-let-vzlamyivaet-domashnie-routeryi.html

В новой публикации рассказано об инструментарии под названием CherryBlossom, созданном специально для взлома домашних роутеров.

Благодаря CherryBlossom можно перехватывать управление над различными моделями роутеров. Заражение вредоносом может быть осуществлено как удаленно, так и сотрудником ЦРУ, работающим «в поле».

Список задач, которые может выполнять устройство, разнообразен. Заражённый роутер может сканировать локальную сеть жертвы, следить и контролировать трафик пользователя, перенаправлять его на необходимые ЦРУ сервисы. CherryBlossom может создать VPN-тоннель к сети жертвы, выполнять ещё ряд действий с URL, email и MAC-адресами.

В списке зараженных CherryBlossom устройств значатся более 200 моделей роутеров самых разных производителей:

Наивные хомячки домашние пользователи могут продолжать верить, что «они никому не нужны», им «нечего скрывать», а также продолжать не понимать ценность открытых/альтернативных прошивок.

То, о чём IT-специалисты предупреждали деятелей роскомпозора несколько лет назад, таки случилось. Полная ебанутость системы блокировок «запрещОнных сайтоФФ», полный ваккум в законодательстве по технической части и исключительная кривизна системы «ревизор» привели к тому, что опасающиеся неадекватно высоких штрафов (100к рублей за хуйню типа пары незаблоченных урлов) провайдеры по прямому указанию действующих властей заложили самую натуральную атомную бомбу под действующую сетевую инфраструктуру.

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

При этом записи туда в основном только добавляются. Для выкидывания записи из списка либо владелец сайта должен выиграть судебную тяжбу (биткоиновцы, вы молодцы!), либо сам РКН может удалить относительно свежую запись, если посчитает, что ресурс таки пошёл им на уступки.

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

А поскольку промышленный провайдерский DPI — игрушка зело дорогая, да и в законе по технической части весьма негусто (есть только один документ такого плана, и то рекомендательный), очень многие провайдеры делают не только DNS-, но и IP-блокировку, но до появления «ревизора» блокировка средствами днс в основном считалась достаточной (что вообщем-то так и есть — она достаточна для того, чтобы отшить 99% наркоманов от онлайн-покупки наркоты, а против остальных мало что поможет). Потом в реестре появились и IP-адреса — ушлые наркоторговцы просекли, что поднятый прямо на голом IP сайт, без доменного имени, тоже вполне ОК.

А потом появился «ревизор». Проблема этой кривой блядской коробочки (даже не сертифицированной как измерительное средство), что она не просто проверяет доступность сайтов «как есть», но и пытается делать прямые запросы по IP в обход провайдерского резолвинга, причём как по IP-адресам из реестра, так и по текущим IP из DNS. Естественно, с попутной выпиской «предписаний», руганью, штрафами и многомесячными судебными тяжбами.

В итоге провайдеры либо купили системы DPI, либо начали блочить любые полученные адреса, что из реестра (как изначально и было у тех, кто одним ДНС не ограничился), что из динамически обрабатываемого ДНС. Но в отличии от реестра, составляемого цензорами РКН и хоть как-то доступного для управления, в динамический ДНС изменения владелец домена вносит сам по своему желанию.

Bomb has been planted.

Таймер на бомбе тикал долго — аж несколько лет. За это время недовольство деятельностью РКН, давно вышедшей за всякие разумные рамки, достигло пред-критической величины (вообще идея отбирать у народа зрелища при отсутствии хлеба зело не здравая и мaйдaно-опасная). Предположу, что наезд на торрент-трекеры и анонимайзеры стал той последней каплей, после которой противостояние перешло в действительно активную фазу.

Прекрасно зная, что системы DPI стоят не у всех, а IP-блокировки весьма разрушительны, сетевые шутники массово начали заново регать те домены, которые были давно разделегированы регистраторами имён, но всё ещё оставались в блок-листах РКН, и в настройках DNS таких свежекупленных блоченных доменов прописывать IP-адреса враждебных или просто популярных ресурсов, чтобы даже самого ленивого хомячка хоть чуть-чуть, но зацепило.

Вышло классно — у ряда пользователей отвалился телеграм, онлайн-кинотеатр, новостные агентства и прочее и прочее.

Устроенная кибер-анархическая вакханалия вышла годной, и началось прописывание в заблоченные ДНС уже более важных адресов — служебных адресов самих систем РКН, банковских процессингов, и прочей мякотки.

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

Tеrrоrists win.

Но самый прикол, что к участию в вакханалии присоединились даже дети.

Особый смак обнаружился, когда вспыла информация, что IP-блокировками занимались и транзитные операторы, из-за чего сбои многократно увеличили зону поражения.

Ркн в панике начал рассылать «белые списки» исключений, носящие, опять же, рекомендательный характер (в законе про такую муйню вообще ничего нет, как обычно), в попытках хоть как-то остудить оттраханную Сбербанком сраку (боюсь даже представить, какие претензии может вкатать Сбер за поблоченный карточный процессинг).

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

Какое блять нахуй противостояние американской ИТ-разведке ?! Какие ещё нахуй доктрины безопасности ? РКН против вредоносных прошивок АНБ ? Яровая против закладок ЦРУ ?
Деревянные и некомпетентные в ИТ службы надзора в сфере связи против террористов из игил ?
Вы серьёзно ?!

Не смешите, нахрен, мои тапочки.

Уровень современного гос. управления ИТ в Роиссе — это повальные тупые блокировки, причём больше ради штрафов на ровном месте, чем ради реальной безопасности, и 14-летние восьмиклассники, простыми безобидными действиями ценой в 80 центов кладущие к хуям крупные банковские процессинги в масштабах страны руками самого ркн и самих же провайдеров.

Самое вкусное во всём этом — за такую «отаке» шутнику по закону даже предъявить ничего нельзя. Вообще.

Сайты регать можно ? Можно.
Запрещённого контента на сайте нет ? Нет.
Менять DNS на своём собственном домене можно ? Никаких проблем.

А что подложенная силами самого ркн бомба подорвала критически важную инфраструктуру (замечу, без всяких хакеров, хватило шутников из 8 класса) — вина исключительно самого ркн, и никого более. Профессионалы предупреждали.

Какая адская свистопляска может начаться в компьютерных системах РФ (до сих пор массово сидящих на старой винде) в случае реальной атаки силами АНБ или ЦРУ — можно пофантазировать самостоятельно. Думаю, что ванна-край и прочие безобидные конфикеры поблекнут весьма сильно.

P.S. И не надо пиздеть мне про Эльбрус — гос-органы файлы ODT до сих пор не научились принимать, просят ворд, причем 2003-й. Два компьютера на общем фоне погоды не делают.

Если у вас так или иначе реализован мониторинг, то в какой-то момент возникнет разделение событий и сведений мониторинга по степени важности. И почти наверняка вам потребуется отобразить данные из одной системы в другой системе. Суть данной статьи — как вытащить интересующие графики нагрузки, созданные системой Grafana, во внешнюю самописную систему максимально простым способом, например, для отображения на публичном сайте или в любой другой системе.
(далее…)

В прошлой статье про PXE я описал массу способов сетевой загрузки самых разнообразных осей с USB-флешки домашнего роутера.
С тех пор вышел новый кноппикс — 7.7.1, и помимо обновления (с выхода версии 7.6 прошёл год), мне хотелось иметь возможность грузить полноценное рабочее место с x64-ядром, поскольку объёмы памяти и аппетиты приложений только растут.
Что из этого вышло — читаем ниже.
(далее…)

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

На один конец патчкорда вешаем специальную светилку:
http://laserbeam.ru/power/fiber/ft650

А второй конец направляем на любую ровную поверхность.

В случае исправного патчкорда на выходном разъёме будет слабо светится только точка выходного среза, вся световая мощность вылетит наружу:

cable_ok

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

Если у разъёма есть даже небольшой дефект, то свет из волокна конечно выйдет, пятно будет на освещенной поверхности, но ощутимая часть света рассеится в белой керамической вставке коннектора:

cable_half-ok-1
Линк через такой провод может быть нестабилен или вообще не подняться, если оптического бюджета не хватит на длинную линию.

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

Если вы читали мой блог, то возможно, видели статейку про бэкапы и их копирование по SSH. Там был пример, как с помощью одной строчки вытащить конфиг джунипера себе на комп.

Однако есть железки, у которых управляющих модулей внутри может быть больше одного. Например, в Juniper MX960

Juniper MX-960

может быть несколько (чаще всего два) так называемых routing-engine (RE, вертикальные модули в середине железки), представляющих из себя полностью независимые управляющие компьютеры со своими процами / памятью / дисками. В каждый момент времени работает только один такой комп, второй находится в горячем резерве и готов взять на себя все функции при отказе первого. Особенность в том, что заходя на такой джун по SSH, вы всегда будете попадать на Master-RE, и команда show config будет показывать именно текущий рабочий конфиг с мастера.

И хотя в штатных случаях конфиги и версии прошивок должны быть одинаковы (первое задается через set system commit synchronize в конфиге или ручками при commit synchronize, второе вопрос организационный), могут возникнуть ситуации, когда конфиги не совпадают. В этом случае лучше в бэкап записать конфиги с обоих устройств. Однако просто так по SSH зайти на Backup-RE нельзя — он не управляет никакими интерфейсами, и на нём даже не запущен роутинг. Также мы не можем заранее 100% знать, какой из RE сейчас мастер — это может менять в процессе использования / ребутов / обновлений прошивок и прочего.

Решение есть в самой джунос и оно прекрасно:

#!/bin/sh

# My backup script on backup-storage server; login over read-only class user to junipers

# Бэкапим текущий мастер-RE как обычно:
ssh {IP} "show configuration | display xml" > mx960-Master-RE.xml 2>/dev/null

# Бэкапим текущий резервный-RE более хитрой командой:
ssh {IP} "request routing-engine execute routing-engine other command \"cli show configuration | display xml\"" > mx960-Backup-RE.conf 2>/dev/null

# Бэкапим конфиг именно первого RE, независимо от его роли
ssh {IP} "request routing-engine execute routing-engine re0 command \"cli show configuration | display xml\"" > mx960-RE0.conf 2>/dev/null

То есть мы заходим таки сперва на текущий мастер, и говорим ему выполнить заданную команду (важный момент — под командой тут понимается команда FreeBSD-шелла, а не команда JunOS-консоли cli !), в данном случае — вызвать консоль JunOS, а ей уже передать команду отображения конфига на соседнем ядре. Вывод ловит уже наш SSH. Действо простое, понятное и безопасное. Не забываем заэкранировать кавычки для JunOS-команды.

Обнаружил тут, что после обновления битрикса появилась эта рекламная кнопка. Я немного охренел от того, что при апдейте КОММЕРЧЕСКОЙ цмс с очередным обновлением что-то вообще поменялось в макете сайта, и сперва подумал, а не хаканули проект случаем. Как оказалось нет, ничего не хакнули, просто один-цэ решила немного порулить чужими сайтами в выгодном для себя ключе за ваши деньги. Ведь не все же могут влезть в настройки.

(далее…)

Настраивая или проверяя какой-либо драндулет на никсах (неважно, десктопного или серверного применения), полезно знать, нет ли в системе старого уязвимого софта мохнатых версий.

Нашел для этого совершенно изумительный сервис:

https://vulners.com/#audit

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

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

Огромный плюс — не требуется ставить никакой софт, запускать мутные сркипты и вообще пускать кого-либо в свои владения. Поддерживается дебиан, федора, центос, редхат и оракля. И убунта, куда же без неё.

Фряха не поддерживается (да, оно ещё вполне себе живо), увы.

мистика и Juniper

Posted: 2016-05-29 in IT
Метки:

Ситуация :


May 29 11:00:03 ex4200-24f-sw1 chassism[1332]: AN_BYPASS Activated for port ge-0/0/2
May 29 11:00:03 ex4200-24f-sw1 chassism[1332]: AN_BYPASS: Link down, Restored config on bypass activated port ge-0/0/2
May 29 11:00:03 ex4200-24f-sw1 chassism[1332]: AN_BYPASS : Port ge-0/0/2 Saved time -75044563
May 29 11:00:04 ex4200-24f-sw1 chassism[1332]: AN_BYPASS : Port ge-0/0/2 Current -75043561 Saved time -75044563

Гуглинг даёт пару невнятных ссылок на англоязычные форумы. У нас нет ни LACP на этом порту, ни стекированных железок.

Симптомы — один из оптических линков лежит в дауне (Hardware Down), других флагов ошибок в show interface не фиксируется, после замены оптического модуля / перетыкания в соседний порт работает несколько часов и снова падает.

Первая идея: проверить синхронизацию времени. У нас время как раз было плохо синхронизировано, мантры deactivate / activate ntp (с последующими коммитами) в секции #system не помогли, делаем так:

> start shell
$ su
# which ntpdate
# /usr/sbin/ntpdate -u pool.ntp.org

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

Если прописано несколько NTP-серверов в #system ntp, то стоит проверить, что с каждого можно получить время командой ntpdate, и недоступные NTP-серверы либо поднять, либо удалить из конфига.

Помним главную заповедь админа:
«[После этого] ещё не означает [из-за этого]».

Но самый прикол в том, что хоть восстановление синхронизации времени и решило проблему, но снова лишь временно, пусть и на существенно больший промежуток времени.

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

Есть такая специализированная учётная система для провайдеров — UserSide. Хотя по мне так, она будет крайне полезна для любой более-менее крупной сети, например в бизнес-центрах. Штука совершенно замечательная в плане всякого учёта девайсов, линков, привязок абонентских портов, мониторинга состояния, учёта заявок и прочего. Софт — конфетка.
И там очень классно сделан опрос и мониторинг статусов портов на оборудовании.
Но если на железке число портов не фиксировано, то могут возникнуть сложности. О чём и расскажу.
(далее…)

QinQ — Часть_2, про Juniper

Posted: 2016-04-15 in IT, Networks
Метки:

Всем привет. Сегодня я расскажу об особенностях настройки Q-in-Q на джунипере, а конкретно — на Juniper EX-4200. Ну и про замеченные багофичи тоже не забуду упомянуть.
(далее…)

Перепостить это древнейший боянЪ меня сподвигла длительная изматывающая борьба с глюками мультикастового IPTV.
(далее…)

D-Link DVG-5402SP nano-howto

Posted: 2016-02-25 in Hardware, IT, Networks
Метки:,

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

* Для сброса настроек ресет надо нажать при ВКЛЮЧЕННОМ девайсе и держать 5-8 секунд подряд, НЕ СБРАСЫВАЯ ПИТАНИЕ, пока не начнёт часто мигать индикатор [Prov./Alm.]
* default-IP :: WAN: DHCP, LAN: 192.168.8.254/24
* Фирмварь обновлять обязательно.
* Не забыть включить приоритет кодеков и прописать SIP-прокси строки, включение реги и Display Name (в статусе светится как Extension Number!!) в обе линии.

+ дешёвый
+ 4 порта LAN, для операторского места (инет на 1-3 компа + два теплых ламповых телефона) вполне ОК.
+ быстро грузится (секунд 10 с воип-регистрациями)
+ резервный FXO для переключения на аналоговую телефонию при отказе VoIP
+ даже IPTV/Multicast немного умеет
+ QoS для VoIP

— нет WiFi, совсем
— доступ из WAN по HTTP закрывается указанием порта 0 в настройках
— настройки файервола полное гуано
— Full-HD поток из IPTV ставит девайс раком, 40-60% потерь пингов через forward/nat, не-HD каналы ОК
— iperf по TCP показывает всего 9-12 Мбит, по UDP 70-82 Mbit
— Пароли длиннее 10 символов не умеет. Поставить можно, но потом будет на зайти веб-мордой
— телнет светит всему миру
— про SSH, L7-DPI и прочие страшные слова сей девайс даже не слышал.