​Заканчивающаяся неделя опять нам подкинула новостей про суверенный интернет. Интересная тема в разрезе роли государства в капиталистическом обществе. Понятная цель заботы о собственной безопасности, правда понятная. Но если хочется безопасности и надёжности, я бы строил свой интернет - новый, со всеми академическими выкладками, расчётами и проектами на каждом уровне, чтобы понимать что если у тебя выпало больше положенной нормы осадков в какой-нибудь области, то вероятность выхода из строя магистрали Москва-Камчатка вырастает от 30% до 70%. И да, это будет дорого. Очень.
Но когда всё будет построено будем иметь хороший резерв для стратегических ресурсов. Это уже отдельная задача определить какие ресурсы стратегические и являются ли таковыми Госуслуги или не являются. А потом предоставить всем операторам связи на некоммерческой основе данный резерв, чтобы стратегические ресурсы были доступны всегда. Так как их количество сильно ограничено, то и трафика там не много. А если учесть что это только резервный путь, то можно строить на очень непроизводительном оборудовании со всеми слоями шифрования, для чего отечественная промышленность уже готова. А обычный Интернет пускай им и остаётся. Наверное, я за такой путь, мне он был бы понятен.

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

Вряд ли подобная карта есть вообще у кого либо из операторов, в лучшем случае она детализирована до оперативно необходимой степени и не более. У нас есть отдельно L2 связности ("бумажная"). Отдельно L1 тоже "бумажная" в нескольких вариантах, отдельная для строителей, отдельная для админов, ещё и в разных форматах. Некоторые участки этих карт детализированы чуть сильнее - добавлен L3 уровень. Из электронных вариантов есть автоматическая карта виланов и адресного плана, который есть отдельно ещё в "бумажном" виде.
С натяжкой можно сказать что таблицы маршрутизации и есть та самая карта, причём определённая формально и строго математически, подходит для анализа и расчётов. В ней уже показаны оптимальные и резервные маршруты. Но она покрывает опять же, только один из уровней, часто какой-то средний.

Как себе представляет это и что будет делать РКН - вопрос. Сейчас есть реестр инфраструктуры связи в котором ведётся количественный учёт операторов и некоторых из их характеристик для населённых пунктов (не всех). В частности можно узнать максимальную и минимальную заявленную скорость провайдером, количество теле- и радиоканалов, количество таксофонов и почтовых отделений. Это интересно, но мало, очень мало и поверхностно, например совсем нельзя понять кто от кого зависит. RIPE NCC или Qrator со своей картой BGP связности знает больше об этом. И это только BGP, что далеко не всё.

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

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

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

Посмотрите на https://gchq.github.io/CyberChef/ - есть ещё похожий проект https://cryptii.com/

У британского аналога нашей Спецсвязи ФСО (которая раньше была ФАПСИ), GCHQ (Government Communications Headquarters) имеется своя скромная страничка на гитхабе, с весьма интересными и не скромными проектами. Сплошная бигдата, анализ и шфирование. Интересно, насколько эти проекты отстают от того, что у них в проде. Хотя не исключено, что весь репозиторий создан просто для отвода глаз.
https://github.com/gchq

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

ping в Linux реагирует на SIGQUIT выводом промежуточной статистики. Это работает и удалённо через SSH - комбинация клавиш CTRL+4 или CTRL+\. Во FreeBSD не реагирует.

"Во FreeBSD и MacOS есть SIGINFO. Доступен по ^T" - добавляют наши подписчики. Большая благодарность от меня за ваши пояснения и участие. Реакция ping будет аналогична как в Linux.

man по всем специальным символам и действиям в терминале для FreeBSD и Linux.

​Просто Doom3 на WebAssembly в браузере, работает! Подробности проекта. А у меня ещё удивление от Vim не прошло.

Большой отчёт Qrator про работу (отбивание атак) и изменения в самой компании за прошедший год.

Если в Cisco NAE поменять пароль через вебинтерфейс, то он не поменяется для CLI. Если вообще не заходить в консоль, а настраивать всё через Web то он останется паролем по умолчанию с завода.
Ничего сильно криминального (хотя как посмотреть) просто опять всплывает вечная проблема поддержки двух разнородных интерфейсов, наверное разными командами разработчиков. При этом производитель (это не только для Cisco характерно) берёт на себя очень много и решает за потребителя что лучше и как ему удобнее - включил и всё работает. В итоге, получаем сразу очень много активированных опций, часто запрятанных очень глубоко, которые не нужны в работе, но потенциально небезопасны.

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

https://bashrcgenerator.com - удобный конструктор приглашения командной строки.

Я не знал и забыл: точка в почтовых адресах Google не имеет никакого значения.
[email protected], [email protected], [email protected] - это один и тот же адрес. Мой друг вчера рассказал и очень удивлялся этому факту, теперь я удивляюсь вместе с ним. Говорят что коллизий не должно возникнуть... говорят.

У D-Link есть такая штука как cable_diag:

100BASE-T Link Down Pair 2 Open at 61M

Есть достаточно давно. Удобная вещь в диагностике последних 100 метров до абонента и хороший аргумент для монтажников.

А на Cisco такое делать почему-то не приходилось, не часто они мне на доступе попадались всё больше ядро да агрегация. Но у них тоже есть. Метод называется TDR, чтобы было что искать в Google. И у Juniper.

Cumulus Certified Open Networking Professional. Собственно сертификация Cumulus по современным Linux сетям как это видят они. Специфичные темы есть, но не очень много. Под каждую тему есть свои курсы, так как смысл сертификации в знаниях, а не в бумажке. Сдаётся удалённо под присмотром проктора. Не Cisco единой.

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

Давненько я не натыкался на явные баги в работе. Подготавливаю новую логику для FreeRadius, правлю preprocess/hints, а там нельзя использовать регулярные выражения если включен Fall-Through. То есть можно конечно, но всё падает.
Уже всё пофиксили месяц назад, но пересобирать на боевых серверах мне как-то не очень. Тем более, что можно просто немного конфиг усложнить - повторив нужные действия в каждом элементе выбора, благо у меня там всего их два намечается.

Простая утилита для сравнения объёмов IPv6 и IPv4 трафика. Никаких заморочек, просто анализ pcap или живого потока с tcpdump. Надо будет скомпилировать или взять готовые бинарники c GitHub.

На ближайшем NetDev 0x13 будет доклад на тему использования неиспользованных до сих пор IPv4 адресов, таких как 240/4 зарезервированных для будущего. Это 1/16 вообще всех адресов, ни разу не используемый класс E. С учётом всех других специальных и неиспользуемых диапазонов, получается приличное количество.
В аннотации говорится что работа ведётся хотя была остановлена 10 лет назад, даже тестирование намечается, но надо будет слушать докладчиков. Вопрос в том наступило-ли то самое будущее? IPv6 берегись!

CloudFlare свой набор инструментов для RPKI выкатила. Чем больше тем лучше. Если даже только большие будут проверять (что сложнее) и отбрасывать, а все остальные только подписывать (а это совсем просто) уже будет хорошо.

Для тех кто уже решил вопрос автоматизировать или нет, есть второй вопрос. Использовать что-то готовое, например, Ansible, формируя только шаблоны настроек. Или использовать фреймворки и писать программы самому, встраивая управление в используемые системы.
Для второго варианта есть решения вроде NAPALM который недавно обновился до версии 2.4.0. Или Juniper PyEZ с которым ещё проще разобраться посмотрев простой пример.

P.S. Для тех ещё кто не определился - автоматизируйте! Ключевые слова для поиска: git+ci, chef/salt, puppet, terraform - помимо того что выше написано. Даже свой костыль в этом случае лучше, чем вручную править конфигурацию даже для 10 устройств. Выбор есть и это хорошо.

IPSLA как в Cisco только на Juniper. Может когда нибудь найду где это использовать, но пока не приходилось. Цена ошибки в провайдинге это десятки гигабит/c не туда, в каналы стоимостью сотни тысяч рублей. Если маршрутизация не кладёт что-то автоматически, значит это сделает дежурная смена с прицелом на текущую ситуацию.