Патчкорд

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

Перед новым годом я предпринял 100500 попытку пересесть на Vivaldi и пока остаюсь на нём. Это не рекомендация, скорее наоборот, вам нужно очень сильно полюбить Vivaldi, чтобы пользоваться этим браузером более менее постоянно. Я даже не могу объяснить что не так, всё на уровне ощущений. Браузер, в принципе, не мой рабочий инструмент, от слова совсем, я не пользуюсь горячими клавишами, у меня нет синхронизируемых данных и плагинов, у меня даже новых закладок не появлялось последних лет пять, хотя я иногда и захожу в инструменты отладки, но там Chromium, как и везде. Это даже никак не связано с тем что я сидел до этого на Opera дома, которая слабо похожа на саму себя десятилетней давности, а как выглядела "та самая" Opera я уже не помню. На работе у меня Edge и я не планирую с него уходить, но опять же, браузер даже не третий мой рабочий инструмент. На Vivaldi я перешёл только по одной причине - встроенный почтовик и RSS. Вот те самые ощущения общего инструмента браузера и почтовика из Opera, я как раз хорошо помню. Почтовик чрезвычайно простой, получить/отправить, есть метки и флаги и после перегруженного и неповоротливого Thunderbird я прямо выдохнул. Но перенос архива писем примерно с 2006 года, таки забрал у меня пару дней, встроенный мастер не справился с этим, хотя справился с закладками. Что мне надо и чего нет ни в одном популярном браузере это опция игнорирования параметров безопасности SSL/TLS с возможностью принимать любые кривые сертификаты с самыми устаревшими протоколами подписи и шифрования. Но таких нет, для этого у меня стоит старый Firefox, чтобы попадать, например на свой на современный принтер HP, работающий по общепринятым стандартам шифрования 2010 года.

Общий вилан в принципе не очень идея, а если вы его к тому же разделяете между устройствами с маршрутизацией не обладающими одинаковым и полным списком маршрутов. Иван Пепельняк пишет про современные ASIC, нагрузку на CPU и ICMP Redirects, что может быть проблемой, наверное. Но основная беда это то что вы можете потерять трафик и это далеко не единственный сценарий. Странных, откровенно плохих или на вид хороших топологий сети с общими виланами можно придумать очень много, хотя места где это надо, IX например. Два года назад я сказал бы что это надуманная проблема с ICMP Redirects, но тогда у меня и общих виланов не было, а теперь есть и уже пришлось переделать так чтобы всё работало в ситуации почти один в один приведённой в статье.

Детальный разбор уязвимостей роутера GL.iNET начиная от поиска до эксплуатации, название мне ни о чём не говорит, первый раз слышу, но смысл не в названии. Для каждой найденной уязвимости, приводятся также шаги с временными отметками от момента обнаружения, через заведение CVE, до выпуска устраняющей проблему прошивки. Но этого мало, во второй части автор разбирает остатки до винтика, ломая аппаратную часть.

packetvis.com - сервис для мониторинга BGP ресурсов, не только собственных. Позволяет увидеть всевозможные ошибки, включая ошибки конфигурации, ошибки распространения, попытки перехвата, неверные настройки RPKI. Есть уведомления и API, нужна регистрация.

Файрволы работают хорошо скрывая своё присутствие, но понять что у тебя в середине именно файрвол можно, если хоть какой-то ответ возвращается. Здесь автор подаёт это как открытие, но именно так, фильтруя по TTL, вставленные системой фильтрации DNS ответы, мне удаётся в этом моменте обходить файрвол, скорее всего пока. Раньше можно было обходить гораздо больше (обратите внимание на hlim), сейчас приходится строить туннели. Технологии подтянулись, но скорее доступных мощностей выделяемых на фильтрацию стало больше. В статье, помимо момента с TTL, показывается как посылать TCP RST с помощью Palo Alto, если у вас вдруг Palo Alto и вы ещё этого не знаете.

Наткнулся на ttyd - утилиту которая прокидывает терминал Linux в Web. Сначала подумал зачем, а потом вспомнил что сам таким же занимался для Cisco, что называется средствами из коробки. Не знаю заработает ли моё решение сейчас, но вроде ничего серьёзно там не поменялось за это время. Для Linux, конечно, стоит выбрать ttyd или написать своё.

Что такое и зачем нужен VXLAN, первые два поста из запланированной серии. Помимо теории есть и примеры конфигурации на заданной топологии.

Ежегодные графики по размеру BGP таблиц в IPv4 и в IPv6 и детальный расклад (по другим графикам) от Geoff Huston. Чем отличается только что закончившийся год от предыдущих? Рост BGPv4 замедляется и в этом году составил около 35000 префиксов, вместо 50000, два года назад было около 40000, а до этого стабильно по 60000. Такими темпами до миллиона в 2023 не дотянет. Общий размер сейчас 935000, если смотреть с этого места. Рост BGPv6 в этот раз не ускорился и показал плюс 30000 префиксов как два года назад, в прошлом году было плюс 40000. Общий размер около 170000. Позапрошлый год я уже называл необычным (время карантинов), этот год обычным тоже не назовёшь и по динамике он как раз больше похож на позапрошлый чем на прошедший, как минимум неожиданная для меня просадка в росте IPv6 префиксов. Если в IPv4 можно говорить о насыщении, то для IPv6 до этого ещё очень далеко. Geoff Huston обязательно ещё сделает обзор на устойчивость BGP таблиц, ссылку постараюсь не пропустить и поделиться. Из уже готовых итогов в большой череде предстоящих публикаций с итогами - RIPE Labs сделал ретроспективу своих статей и событий по месяцам 2022 года. Смотреть за BGP в 2023 году можно в ботах @bgp_table_bot, желательно иметь доступ к Twitter, но может быть я переделаю на Mastodon и @FullViewBGPbot, пока без годовых графиков, но в следующем году всё будет.

Go is evil on shitty networks https://withinboredom.info/blog/2022/12/29/golang-is-evil-on-shitty-networks/

К вопросу о глубинах глубин и то как решения 10-15 летней давности будут вас преследовать и всех остальных пользователей вашего продукта. И, конечно, о знании предметной области, как работает TCP и всё что вокруг него, в частности TCP_NODELAY. Про Kubernetes тоже есть ;)

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

Конечно, кот это не такса, но тоже может иногда.

Вчера в Bird появилась поддержка BGP ролей (RFC 9234). И это не может не радовать. Поздравляю всех причастных, особенно Сашу Азимова и Женю Богомазова. Вы котики :) https://bird.network.cz/

Для BIRD настраивается опциями: local role role-name <provider| rs_server|rs_client|customer|peer> и require roles если не хотим поднимать сессию с соседом который не поддерживает ролей Для FRR: neighbor <PEER> local-role <provider|rs-server|rs-client|customer|peer> [strict-mode] Для OpenBGPD: announce policy <no|provider|customer|rs|rs-client|peer> [enforce] Осталось только пожелать чтобы это стало распространённой практикой.

Yandex nexthop и Пиринговый форум прошли почти одновременно и это хорошая возможность сравнить впечатления по горячим следам, кроме того что они разные и Qrator на обоих представил одинаковый доклад. Пиринговый форум - лучше. Конечно, стоит смотреть и слушать оба если вы не участвовали и ещё не успели это сделать. После просмотра Nexthop у меня сложилось ощущение второй серии - всё было, но всего больше, мы продолжаем продолжать. Я даже специально отмотал на год назад чтобы сравнить впечатления, и понял что они действительно такие. То есть, я не нашёл для себя что-то очень новое, даже подумал, что это потому что я слишком в теме. Из всего того что было, отмечу почти несостоявшееся выступление из Китая, по причине плохой связи про централизованное управление каналами связи для клиентов на своей инфраструктуре без MPLS - свои костыли, это вовсе и не костыли, а очень даже инновации, жизнь без оверлеев на сети провайдера есть, автоматизация решает. А также если вы очень большой и вендор вас очень внимательно слушает и оперативно добавляет все ваши хотелки. Из-за этого у меня были достаточно тревожные ожидания Пирингового форума, но всё получилось вполне динамично. Может потому что темы ближе, а может потому что докладчикам давали времени в два раза меньше. В любом случае можно было услышать позицию RIPE NCC на всё происходящее вокруг включая РАНР, увидеть админку DNS инфраструктуры MSK-IX, завалить новый инструмент daspath.ru и в Телеграме тоже @daspathbot, узнать почему все теперь обсуждают IPv6 в Иви и действительно ли ТСПУ делают Интернет безопаснее. Справедливости ради, скажу что был ещё поток Медиалогистика параллельно, но это вы уже сами, если интересно. Долгожданные, традиционные мероприятия в реале. Смотрите и слушайте.

Сегодня много сообщений о том, что МегаФон похоже наконец-то включил IPv6 везде и для всех. Проверяйте у себя. Уточняют, что название APN должно быть просто "internet", а не "internet.megafon.ru". Режим подключения в её настройках необходимо сменить с v4 на v4v6, если эффекта нет, можно проверить появляется ли IPv6 в режиме v6 (без v4), и потом снова v4v6.

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

Несколько раз за последнее время услышал что нельзя поднять site-to-site туннели IPSec в routed-based режиме с одной стороны с policy-based режиме с другой. Если хочется, то конечно можно. Выбранный режим это не более чем локальный способ отправить нужный вам трафик в туннель, а на уровне IKEv2 всё равно придётся согласовать Traffic Selectors, чтобы сформировать необходимые для работы IPSec таблицы политик и состояний. И вся проблема не в протоколе, а в реализации соответствующего режима. Для policy-based значения TS задаются в явном виде, как например в Juniper или Strongswan, или в Сisco access-list который привязывается к crypto-map. На основе этих значений формируются и политики, здесь уже неявно, которые заворачивают трафик в туннель. При этом обеспечить прохождение трафика через нужный интерфейс с политиками всё равно придётся маршрутизацией. А для route-based нет необходимости явно задавать значения. Про таблицу маршрутизации IPSec мало что знает, поэтому на основе ваших маршрутов, которые заворачивают трафик в VTI интерфейс никакие согласования не выполняет. Вместо этого, по умолчанию используется TS 0.0.0.0/0 - 0.0.0.0/0, посмотрите свои SA в режиме route-based, чтобы в этом убедиться. Таким образом, если настроить такое же значение со стороны policy-based, то всё должно заработать между маршрутизаторами с разными режимами управлением трафика IPSec. Как минимум один такой туннель вы точно сможете построить, в ситуации когда уж совсем не удалось договориться. Второй подобный туннель с policy-based стороны уже может упереться в особенности реализации, потому что одинаковый 0.0.0.0/0 для другого туннеля может иметь неоднозначное значение в политиках, ловил такое на ASA - в двух разных IPSec, но с одинаковыми TS внутри, один из них не поднимется. Наверное, ситуация имеет типовое решение, или обновление, но тогда я просто подробил сеть в одном из туннелей на две половинки, потому что имел доступ к обоим концам туннеля. Лучшее же решение, даже если вы используете route-based режим с обоих сторон - это явно определить traffic selectors. Это можно сделать и в Strongswan, и в Juniper, и в Cisco IOS опцией Multi-SA. Помимо возможности поднимать туннели с любой стороной хоть policy-based хоть route-based ещё и дополнительная защита если упустили лишний трафик в туннель, он туда не пролезет, только дропнуть его не забыть. Конечно, реализация этого может быть не везде, насчёт уже упоминаемой ASA совсем не уверен, да и версии софта должны быть актуальные, но способ с TS 0.0.0.0/0-0.0.0.0/0 один раз сработает всегда.

/24