Патчкорд

Как IPng делали свои сборщики Certificate Transparency logs, в трёх частях: первая, вторая, третья - с достаточно подробным техническим описанием принятия решений и выбора софта и железа. Результаты ищем в списках используемых CT log у Google и Apple.

Я потихонечку мигрирую свои сервисы на нового хостера, вчера переехал @FullViewBGPbot, полёт нормальный, но если что маякуйте. Следом переедет и host-correct.ru с новой начинкой, большое спасибо подписчику за идею как и на чём всё сделать. Ресурсов буду накидывать по мере переезда. Сейчас всё работает IPv6 only, даже неплохо. Конечно, пришлось подключить публичный nat64/dns64, для тех ресурсов которые ещё не могут напрямую, тот же Github. Эксперимент мне нравится, будь у меня всё в качестве клиента и если не надо было бы иметь доступ к Российским сайтам, в частности РКН, откуда я тяну открытые данные по лицензиям, то я бы так и оставил, вполне себе рабочее решение. Но IPv4 придётся всё таки купить (треть стоимости виртуалкуи) и докинуть, но потом.

Трассировка DNS через eBPF, скоро всё в eBPF. Исходный код прилагается.

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

Классика Programming Pearls, живая, но всё же с современными комментариями. Афоризмы и мысли от программистов для программистов, конкретные и общие. Вдруг не читали.

Несколько профилей Wireshark (в конце статьи) для отладки WiFi. Для меня WiFi по прежнему остаётся загадкой до Ethernet уровня, поэтому выглядит совсем непонятно.

Вопросы мироздания проектирования. Что-то можно обрабатывать быстрее, что-то медленнее, если не попасть в нужный расклад, то всё станет медленным, а не как мы проектировали. Часто лучше вообще не делить на быструю часть и медленную и всё обрабатывать одинаково, что в среднем будет быстрее чем если делить. IPv6 Hop-by-Hop заголовку и тут досталось по полной, напоминая нам о несовершенстве реального мира и что все эти пути, быстрые и медленные, появляются не просто так.

Чтобы понять какое шифрование поддерживает DNS, можно спросить у самого DNS, что и было проделано для поиска наиболее популярных способов. DoT победил, DoH (HTTP/2, HTTP/3) на втором месте, никому не хочется возиться с HTTP серверами. Если, как и я, пропустили RFC 9462, то стоит обратить внимание и сделать соответствующие записи.

Городской вайб последнего времени.

Напоминание, что ваш DNS тоже должен быть IPv6. Там много всяких ссылок и объяснений, коротко, без DNS вы даже не сможете получить адрес нужного вам ресурса. Он в принципе не будет существовать, не давая никаких шансов понять что требуется какое-то действие. И это уже вас заставляет организовывать свой рекурсивный DNS с двойной адресацией. Для экспериментов попробуйте со своих IPv6-only хостов github.com, где на DNS есть IPv6 и x.com, где на DNS нет IPv6.

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

Что обсуждали по поводу управления потоками и очередями на сессии IETF: в Интернет одно видео с его специфическими профилями загрузки, заторы плохо и надо их избегать, ширина каналов такая большая, что нет смысла дальше концентрироваться на том чтобы забить её целиком, лучше оптимизировать RTT, поэтому если поддерживать постоянство потока без всплесков, не пытаться выжать максимальную скорость то всем будет счастье, но это не точно. L4S тоже обсуждали.

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

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

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

Посчитали локальные ноды трафик генераторов (как GGC для Google) на IPv6. IPv4 больше, но зависит от места и от трафик генератора, по качеству одинаково. Нашли, что трафик генераторы могут ставить свои ноды в сети других трафик генераторов. В самой публикации много статистики по разным плоскостям, совсем технические вещи про TLS и ROV вынесли в приложения.

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

Доступность NS национальных доменных зон из разных стран. Автор делает выводы о принадлежности anycast/не anycast, что не совсем корректно, тут скорее о географической распределённости. Больше интересны исходные данные в CSV, по которым можно свои выводы сделать.