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

Сторонние DNS можно запретить по возможности и для классического UDP 53 это хорошо работает, с ним можно даже и ответы подменять. А вот для DNS over что-то - сложнее. В этом случае будет запрещён и протокол в который вкладывается DNS запрос, например HTTPS.

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

Как всегда любой инструмент можно использовать по разному и его противоположность то же.

Вдогонку уходящему дню. Помните 512К day в 2014? Тогда BGP full view перевалила за 512 000 маршрутов, а настройки по умолчанию на популярных маршрутизаторах Cisco были как раз установлены максимум в 512 000 маршрутов, что привело к проблемам с маршрутизацией, в том числе, у больших провайдеров. Как об этом писала сама Cisco. Тогда упоминалось, что этому было подвержено не очень новое оборудование.

Прошло 5 лет, таблица BGP Full view растёт почти линейно и сегодня перевалила на 768 000 маршрутов, или перевалит в ближайшем времени, некоторые неточности возможны при подсчёте. По этому поводу на zdnet.com написали целую статью опасаясь за то что опять могут повториться проблемы.

Это, в принципе, могло бы быть, так как многие резонно рассудив подвинули границу как раз к 768 000 маршрутов, а не к максимальным возможным в 1 000 000, чтобы оставить немного места для IPv6 на 120 000 маршрутов, сейчас их реально почти 70 000, и что-то для MPLS и мультикаст. Но 5 лет большой срок, чтобы всё ещё оставаться на устаревшем уже в 2014 году оборудовании и, наверное, мы не увидим больше подобного фиаско. Может быть ещё через 5 лет, когда количество маршрутов доберётся до 1 000 000.

Следить за зрелищем :) на любителя, можно тут @bgp_table_bot

Вот тут у немцев похоже получилось построить большую добровольческую Wi-Fi сеть. Больше 1500 узлов на карте с почти 2500 клиентов в Мюнхене и трафика там достаточно. А это только один город из. Выход в Интернет присутствует.
Конечно, не забудем упомянуть ещё связанный с этим проектом мессенджер для p2p сетей. Для простой одноранговой локалки тоже подойдёт.

И ещё про mesh сети и IPv6. В этом случае IPv6 снимает практически все вопросы адресации, мы сразу получаем мало чем ограниченное количество узлов в этой сети. Правда что-то придётся придумать с маршрутизацией в этом плоском пространстве, зато ничего не придётся придумывать для протоколов обмена полезной нагрузкой, всё остаётся в рамках стека IPv6.
Такую сеть конечно придумали и называется она CJDNS. Как это всё работает и настраивается в статье, за которую большое спасибо нашему подписчику. На Github тоже стоит зайти. И обязательно на Habr за последними новостями, где CJDNS превращается в Yggdrasil.

Что отметил для себя. IPv6 дал столько свободы своими 128 битами после десятилетий притеснений, что у многих появилось желание использовать адрес не только как адрес. А почему бы и нет, это целых 16 байт, в былые времена которых хватало очень на много, на целые программы хватало. Поэтому и появляются проекты вроде 6cn.
Единственное что может случится не так - применение адреса не просто как идентификатора в будущем, возможно, сузит валидное адресное пространство, просто потому что адрес не будет в какой-то алгоритм укладываться. Вот об это стоит подумать разработчикам, а то опять себя в рамки загоним без выхода.

Да, всё именно так. Оригинал картинки с описанием и другими картинками можно найти на сайте производителя.

Проектирование сети лицензированного провайдера в текущих реалиях начинается от средств СОРМ и других многочисленных обязательных механизмов контроля и ограничения согласно нашему законодательству. Прежде чем сделать резервный канал в Интернет 100 раз подумаешь о целесообразности ввиду дополнительной сложности. И конечно это вносит свои поправки к надёжности и отказоустойчивости.
Даже на этой картинке видно что функционально для доступа к Интернет совершенно нет необходимости в большей части этой схемы. Можно оставить биллинг, радиус, коммутаторы и маршрутизаторы, BRAS. NAT и DPI по желанию. DPI, в принципе, полезная штука для анализа, его можно использовать во многих случаях на благо. Получаем решение без СОРМ минимум в два раза проще.

Статья на Habr про это, наверное, вы её уже видели. Там такие же правдивые, но не такие детальные схемы топологии сети провайдера. Можно и другим способом организовывать, но принципиально не сильно большая разница.

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

1. Конечный результат должен быть простым и понятным всем, никакие дела в одиночку не делаются, отсутствие понятного результата приведёт как минимум к спорам о целесообразности этого решения.
2. При этом, решение на момент завершения работы не должно успеть устареть, то есть изначально надо иметь план с прицелом на будущее. Если так не планировать, то в процессе реализации может появится что-то другое, доступное, понятное и дешёвое, перечёркивающее текущий проект на корню. Тут стоит учитывать что этим новым могут быть собственные знания и опыт, тогда через какое-то время может показаться что вы делаете полную ерунду.
3. Если переборщить и распланировать что-то ультрасовременное, то работа встанет ровно до того момента когда ультрасовременное не превратится просто в современное. Встанет по многим причинам, от банальной нехватки каких-то новых материалов, до психологического принятия этого решения.
4. В любом случае будет что-то новое и это новое встретит определённое сопротивление, может даже со стороны начинателя проекта. Результат и работа всегда вначале кажутся сложными даже переусложнёнными, бывает что это действительно так, но в большинстве случаев это боязнь новизны, это возвращает нас к первому пункту.
5. Даже без формальной документации план должен быть. Просто потому что скорость течения проекта непостоянна, в какие-то моменты будут провалы по времени, возможно, на месяцы и всегда надо быть готовым вернуться к работе в нужном месте.
6. К таким остановкам надо быть готовым, тут спасает чёткое понимание результата. Минимизировать простои помогает деление большой задачи на мелкие шаги, какие-то из них обязательно можно будет делать параллельно, оставить застрявший этап и делать то что можно в данный момент.
7. Надо стараться выдержать начальную архитектуру. Обязательно появится соблазн что-то поменять на ходу и что-то обязательно придётся поменять в большей или меньшей степени. В основном происходят банальные вещи, что-то не успели купить или доделать, на общем фоне мелочь которую можно решить чуть другим способом. Но часто это остаётся нерешённым, поэтому архитектура наша всё, ошибки в ней дорого обходятся, но к костылям стоит приготовиться.
8. От чего-то придётся отказаться. Это случается, например, по причине, что изначально слишком много подстелили соломки, или удалось получить устройство для которого само решение упрощается без дополнительных плясок с бубном, или накопленные знания позволяют пересмотреть кусок реализации. Каким бы ни был изначальным красивый замысел за который хочется держаться, если можно упросить - стоит упростить, но не сильнее чем требуется.
9. В самом конце желание подставить костыли или всё бросить нарастает, хочется побыстрее всё закончить любым способом, потому что надоело. Если есть чёткие сроки то это усугубляется. Остаются мелочи которые, кажется, можно не доделывать, ведь большая часть уже работает и так. Сила воли и чёткий план, но в основном сила воли должна помочь. Работа славна концом.

Для тех кто работает в консоли, в которой тоже можно красиво, а не только в командном режиме.

Termshark - псевдографический интерфейс для консоли как в Wireshark. Если tshark мало, а GUI не хочется.

И sandmap - консольный интерактивный интерфейс для nmap. Тут попроще, добавили комментарии и сделали каталоги готовых шаблонов использования.

Если какой-то ресурс в Интернете перестал быть доступным, то возможно потому что кто-то по пути до него не удалил уже не анонсируемый префикс. Статья на lab.ripe.net про это. Коротко - да такое явление существует, но причины этого неизвестны. Скорее всего проблема в маршрутизаторах и их ПО.

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

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

Про современные немного поостывшие тренды, разве что Kafka везде мелькает. Но к теперешним AI (Искусственному Интеллекту) и ML (Машинному Обучению) относится в полной мере. Разве ты Google? - статья про то что инструменты надо выбирать сообразно проблеме, для простоты можно воспользоваться методологией UNPHAT:

1. Understand - поймите в чём проблема
2. eNumerate - дайте себе возможность выбора, рассмотрите несколько инструментов
3. Paper - изучите каждый из инструментов
4. Historical - и практику его применения
5. Advantages - после этого выбирайте по объективным признакам
6. Think - а теперь принимайте решение

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

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

Если уж анонсировали, то можно посмотреть что получилось. Презентации и видео со встречи UPTIMEDAY 2019-04-12. Формат почти часовых выступлений немного утомителен если не смотреть их в живую, получается больше воды и не всегда понятные без сопровождения презентации. Зато разных тем не так много и можно перематывать записи :) Загружу себе в телефон, буду по дороге слушать.

Настоящий, первый черновик BGP. На картинке, как я понимаю, конечный автомат состояний BGP.

В большем разрешении, отсюда. Спасибо за ссылку нашему читателю, без вас - никак! Сравнить с тем что получилось в итоге можно в RFC 1105.

RIPE NCC ведёт статистику распределения своих ресурсов: ASn и адресов с указанием страны. Это достаточно лёгкий способ приблизительной геолокации, не абсолютный, но во многих случаях достаточный. Эту информацию можно видеть непосредственно по whois в базе - атрибут country объекта inetnum. Или на ftp://ftp.ripe.net/pub/stats/, где данные собраны в одном файле, включая IPv4, IPv6, ASn, который удобно обрабатывать автоматически. Присутствуют данные для других RIR и исторические данные.

Простейший скрипт разбора, буквально в 10 строчек, описан тут blog.erben.sk. И даже уже есть готовый актуальный разбор по странам, правда только для IPv4.

"Есть поля, Нео - бескрайние поля, там циски даже не рождаются - их выращивают". Здесь уж точно не придерёшься, что в ручную быстрее будет, без автоматизации.

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

Об этом много и подробно написано в статье про измерения задержек, за авторством Tyler Treat, по мотивам выступления Gil Tene (2015 год, но там такие понятия которые сложно пошатнуть). Приводится пример с нагрузочным тестированием, на сколько неправильное усреднение приводит к искажению реальности. Общий вывод - мониторинг не может быть в отрыве от измеряемой системы, используйте базовый уровень для выработки SLA. Не надо ориентироваться только на 95 перцентиль, 99,999 перцентиль или сколько угодно девяток перцентиль, без реальной системы он ничего не значит.

Но это всё имеет смысл если у вас есть измерения. Мониторинг очень важный аспект работы системы, не зная что происходит невозможно ни чинить ни прогнозировать. ICMP echo уже могут много показать. Для этого, например, есть SmokePing, который измерят задержки используя большое количество инструментов, в том числе и пробников. Хватит на многое.

Отличная новость !
OpenBGPD 6.5p0 released

Это первый релиз в версии portable. Функционал пока урезан по сравнению с версией для OpenBSD (не умеет апдейтить FIB).
Попробовать можно тут - https://openbgpd.org/ftp.html

Ну и к первомаю (на самом деле раньше), релизнулся OpenBSD 6.5 - https://www.openbsd.org/65.html
, так что полный не-portable OpenBGPd можно пользовать там.

Главное в юридической проработке IT-проекта не прийти к такому

1 мая 1964 впервые был использован BASIC. В своё время было сложно пройти мимо него и я не прошёл, хотя он и не стал моей любовью.
Сейчас не так, я даже с трудом смог бы что-то порекомендовать вместо. BASIC специально создавался чтобы все могли программировать и даже первая буква в его названии об этом говорит. Сегодня идея "все должны программировать" звучит очень громко, а такого языка каким был тот BASIC - нет.
По ссылке статья в Time, стоит заглянуть.

IPv6 всё ещё очень молодой протокол, очень. OpenBSD 6.5:

001: RELIABILITY FIX: May 3, 2019 All architectures
If a userland program sets the IPv6 checksum offset on a raw socket, an incoming packet could crash the kernel. ospf6d is such a program.

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

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

Но BGP медленный, и вряд ли, в глобальном смысле, вообще синхронизирован на каждом из узлов участников. Насколько медленный посчитал Ben Cox и написал в своём блоге.
Принцип простой - запускаем счётчик (очень точный), анонсируем префикс и принимаем его в разных частях света. Меняем провайдера, повторяем. Худший провайдер Level3, время приёма префикса через которого от 18 до 50 секунд. У остальных сильно лучше, как правило всего пару секунд.

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

P.S. Часть статей из блога blog.benjojo.co.uk переведены на русский язык, соответствующие ссылки добавлены автором в оригиналы.