Патчкорд

Сервер для проверки замедления доменов t.co который сделал Леонид Евдокимов. Обсуждение здесь. https://speed.gulag.link/ Снизу и сверху тесты скорости до одного и то же сервера, разница только в доменах: Первый t.co.speed.gulag.link Второй speed.gulag.link UPD: Если вы видите значительную разницу в скоростях, значит вас тоже опустили. Обычно если проблема есть, то сверху будут значения около 0.1 а снизу >1. Не смотрите на абсолютные значения скорости, значение имеет только разница. Это дешевый сервер в Scaleway с узким каналов.

APNIC выбирает Knot для работы с подписями DNSSEC, статья про то как, что и с чем сравнивали.

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

Тема разговоров во всех профильных чатах уже вторую неделю. Да, процесс идёт. ТСПУ, возможно ещё не на боевом дежурстве, но по местам уже расставлены/расставляются. DNS в том числе, но это меньшее из зол. Плюс к нему netflow, BGP пиринг, SNMP. Для всех кто имеет AS, но операторы всё равно больше всех попадают. Грусть, печаль... прошлого не вернуть, теперь это новая реальность.

Наши подписчики добавляют лоск: ~$ : | openssl s_client -connect google.com:443 2>&1 | openssl x509 -noout -dates notBefore=Feb 17 12:27:54 2021 GMT notAfter=May 12 12:27:53 2021 GMT "не надо echo, достаточно true, built-in которого в bourne shell - это : и в /dev/null тоже не обязательно слать. Ещё важный момент, сервер может отвечать bundle из сертификатов, а openssl возьмёт только первый и для него выдаст dates, правда, первый обычно в цепочке такой и будет выпущен именно для хоста, а не intermediate или ca root."

Простая утилита, по сути обёртка над уже готовыми модулями Python - dnc, для получения A, AAA, MX и даты завершения TLS сертификата на этом домене, если есть. Пример возможности сделать в точности то что хочется, с минимальными усилиями. Я бы даже сказал что тут и программирования нет - утилитарный подход к проблеме. Почему я обратил на неё внимание, это получение даты окончания действия сертификата из командной строки. Используя openssl это делается вот так: openssl s_client -servername $domain -connect $domain:$port 2> /dev/null | openssl x509 -noout -enddate Если у вас Windows, как у меня, то добавьте echo | в самом начале, иначе придётся Ctrl+C нажать для завершения и замените /dev/null на nul.

Как работает IPv6 в проводе, серия из 7 постов с детальными объяснениями, в том числе и в сравнении с IPv4. Дампы, схемы, теория - всё включено. И я всё ещё советую почитать Ярослав Тихий. "IPv6 для знатоков IPv4". Что-то конечно устарело, механизмы перехода, как минимум, но в целом, к моменту написания база протокола уже сформировалась и вся теория применима. Кроме того, некоторые вещи для IPv4 станут понятнее, например MLD, он же IGMPv2 для которого материалы на русском не так часто встречаются.

А если с базовой фильтрацией уже разобрались и хочется следовать современным тенденциям, то вот примеры настроек фильтрации с помощью RPKI для многих продуктов. Не упускайте из виду, что помимо настроек на роутерах нужен валидатор, ссылки есть в тексте. И будьте пожалуйста ОЧЕНЬ внимательны к любой фильтрации. Мне об этом часто пишут коллеги, что я чересчур категорично подхожу к этому вопросу и для всего есть нюансы. Поэтому прежде чем что-то рубить, вроде тех же INVALID ROA убедитесь что они действительно не нужны даже в таком статусе. Свяжитесь с источником и узнайте причину, помогите в конце концов с настройками. Помимо этого, многие рекомендации противоречат друг-другу, так всегда бывает в больших и сложных системах. Поэтому пытаясь что-то фильтровать можно ненароком сломать, например, механизм противодействия DDoS который часто используется с /32 префиксами и сделать хуже чем было. Всё знать не всегда получается, но разобраться в вопросе, перед тем как действовать, просто необходимо.

Половина автономных сетей в Интернет никак не заботятся о спуфинге, конкретно в этой статье исследовался вопрос получения из внешних сетей пакетов с внутренней адресацией, другими словами применяемость BCP84. Рядом идёт и BCP38 о котором я узнал на YaC2013. Спикеры ужасались попустительством со стороны операторов в отношении фильтрации и борьбы со спуфингом, а я, уже не начинающий специалист (по крайней мере я себя таким считал), ужасался тому что слышу о таких вещах в первый раз и являюсь одной из причин текущего плачевного состояния. В итоге, я приехал и всё переделал, не сразу, но мы этим стали заниматься на постоянной основе. Собственно, ситуация не меняется, по сравнению с 2013 как следует из статьи, да и началом 2000-х, когда эти BCP были выпущены.

Ещё больше про SSH и сертификаты в блоге smallstep.com. Тема по которой многие предлагают свои решения. За ссылки большое спасибо нашему подписчику, без вас и вашего участия никуда.

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

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

Некоторые выводы по опыту внедрения IPv6 сетей от лидеров этого внедрения: Ungleich Glarus, LinkedIn и T-Mobile - в двух частях, в самом конце есть сводная таблица. Обратите внимание на пункт про оборудование, наверное, это касается вообще всех технологий, но в данном случае особенно - тесты, тесты и тесты, не доверяйте только словам вендоров, мы всё ещё, да, всё ещё в начале пути. А если ещё немного подождать, то может поколение помнящее IPv4 вымрет (или забудет об этом, как забыли про IPX) и тогда с IPv6 всё будет иначе, потому что ничего другого не будет.

Ещё раз про выбор лучшего маршрута BGP - "N WLLA OMNI". Примеры для каждого шага алгоритма, исчерпывающие объяснения и выводы. P.S. Больше мнемоник для запоминания.

CZ.NIC сделали новую утилиту для нагрузочных тестов DNS с поддержкой DoH, DoT и остального за компанию - DNS Shotgun, документация и исходники.

Вставляете вывод traceroute сюда - rich-traceroute.io и получаете информацию об ASn адресов на каждом шаге со ссылками на RIPEstat. В IPv6 тоже может.

Помните же про 400G трансиверы. Если вдруг не хватает, то всегда можно и LAG собрать.

Минимально необходимые настройки для безопасного использования ваших устройств NX-OS и JunOS: AAA, SSH, SNMP (лучше v3), журналирование, NTP, ACL. Не исчерпывающий, но жизненно важный список.

Для тех кто хочет разобраться в RPKI для BGP досконально - интерактивная карта по RFC. И инструкция к ней на manrs.org, сначала надо разобраться с ней.

И ещё раз про отличия коммутаторов от маршрутизаторов, современная интерпретация: 1. У коммутатора больше портов 2. У маршрутизатора больше функционала 3. Коммутатор ограничен одной средой, например Ethernet Это конечно помимо того, что коммутаторы смотрят в таблицу коммутации, которая преимущественно заполняется автоматически исходя из передаваемых данных. А маршрутизаторы работают с таблицами маршрутизации, которые заполняется с использованием специальных протоколов. Многие современные устройства могут и то и другое, и это если не касаться темы SDN. Существующая терминология ещё пытается делить всё на чёрное и белое, как это было, ой как много лет назад. Иногда это даже получается.