Плоские сети L2 просты. Любой хост может отправить пакет другому, и сеть его доставит. Если один хост хочет узнать MAC-адрес удаленного хоста, он посылает запрос протокола определения адреса (ARP), и сеть обрабатывает его так же, как и любой другой широковещательный пакет. Удаленный хост отправит ARP-ответ, и все будет в порядке.

Сетевой стек Linux не прост даже на первый взгляд: приложение — в юзерспейсе, а всё, что после сокета, — в ядре операционки. И там тысяча реализаций TCP. Любое взаимодействие с сетью — системный вызов с переключением контекста в ядре.

Чтобы лишний раз не дёргать ядро прерываниями, придумали DMA — Direct Memory Access. И это дало жизнь классу софта с режимом работы kernel bypass: например при DPDK (Intel Data Plane Development Kit). Потом был BPF. А за ним — eBPF. 

Но даже помимо хаков работы с ядром есть такие штуки, как sk_buff, в которой хранятся метаданные всех миллионов протоколов. Есть NAPI (New API), которая призвана уменьшить число прерываний. Есть 100500 вариантов разных tables.

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

Привет! Я Александр Пищулин, перфоманс-инженер в компании YADRO. Сегодня расскажу об одном интересном случае траблшутинга в работе с системой хранения данных — он касается выброса времени отклика. Поиск причин сбоев, наверное, одно из самых увлекательных занятий в моей работе. Зачастую у подобных задач минимальная формализация подхода к решению, каждый раз может быть своего рода открытием или, если угодно, челленджем.

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

Несколько лет назад мы рассказали про то, как Хабр обрабатывает официальные обращения, а также анонсировали наш раздел Transparency report, в котором мы своевременно публикуем информацию об обращениях. Что ж, с тех пор кое‑что поменялось и настало время для новой публикации с небольшим апдейтом.

В Unix-подобных операционных системах общение программы с внешним миром и операционной системой происходит через небольшой набор функций — системных вызовов. А значит, в отладочных целях полезно бывает подсмотреть за выполняемыми процессами системными вызовами.

Следить за «интимной жизнью» программ на Linux помогает утилита strace, которой и посвящена эта статья. К примерам использования «шпионского» оборудования прилагаются краткая история strace и описание устройства подобных программ.

Недавно в нашу компанию «Инфосистемы Джет» пришел заказчик с проблемой долгой реализации создаваемых портов на NSX-T (до 2 минут до момента запуска трафика). Основная боль заключалась в том, что новые поды K8s не всегда укладывались в timeout Health Check'a и процесс начинался опять.

Исходные данные у нас были такие. NSX использовался для построения микросегментированной сети в кластерах Kybernetes + Kyverno. Взаимодействие K8s и NSX было реализовано при помощи плагина VMware NCP. Несмотря на большое количество объектов, в интерфейсе все метрики по утилизации были в «зеленых» значениях, но ощущалось сильное замедление работы UI.

Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.

Добрый день.

Меня зовут Василий и я сетевой инженер.

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

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

Итак, поехали.

Доброго времени суток, коллеги!
Меня зовут Роман и эксперт отдела анализа защищенности (в простонародье — пентестер). До того, как перейти в это направление, я 10 лет был системным администратором (преимущественно Windows систем). Скажу вам честно, мне очень нравится симбиоз такого опыта. На мой взгляд, человеку, который знает внутреннюю кухню администрирования, разработки или их сочетаний, будет легче и интереснее смотреть на инфраструктуру с точки зрения атакующего.

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

• для синхронизации файлов на разных устройствах,
• дедупликации,
• резервного копирования,
• сжатия.

Cloak — это подключаемый транспорт, который расширяет возможности традиционных прокси-инструментов, таких как OpenVPN, Shadowsocks и Tor для обхода сложной цензуры и дискриминации данных.

Руководство будет включать:

1. Предисловие

2. Описание работы Cloak

3. Настройку сервера Cloak

4. Настройку клиента Cloak на OpenWRT

5. Настройку клиента OpenVPN

В серии предыдущих статей я описывал, почему повсеместно используемые VPN- и прокси-протоколы такие как Wireguard и L2TP очень уязвимы к выявлению и могут быть легко заблокированы цензорами при желании, обозревал существующие гораздо более надежные протоколы обхода блокировок, клиенты для них, а также описывал настройку сервера для всего этого.

Но кое о чем мы не поговорили. Во второй статье я вскользь упомянул самую передовую и недетектируемую технологию обхода блокировок под названием XTLS-Reality, и пришло время рассказать о ней поподробнее, а именно - как настроить клиент и сервер для нее.

Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.

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

Но есть большое количество компаний (обладателей номеров автономных систем), которых сейчас в принудительном порядке заставляют использовать "Национальную систему доменных имен" в качестве апстрим-DNS, мотивируя это, конечно же, необходимостью повышения стабильности работы российского сегмента сети Интернет в условиях, когда коварный запад только и думает, как оборвать России связность (а мы их опережаем и обрываем ее изнутри). А побочная функция, что НСДИ не резолвит заблокированные в РФ домены - это так, случайность, неожиданная фича.

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

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

Решение простое как блин, в общем-то. НСДИ детектирует подключение к ней по наличию запросов, но совершенно не может определить, что вы делаете с ответами.

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

Близится кожаная свадьба Роскомнадзора с Телеграмом, именно 16 апреля 2018 года начался крестовый поход, ставший фактически символом уничтожения интернета в России, хотя в глобальной войне, начавшейся в 2012 году, он был всего лишь ярким эпизодом.

Ковровые блокировки в исполнении РКН стали причиной появления на свет множества различных сервисов, помогающих пользователям сети выживать под бомбежками. Одним из них стал antifilter.download, позволяющий получать списки находящихся под блокировками IP-адресов. Далее пользователи сервиса могли использовать полученную информацию по своему усмотрению. Одно из таких усмотрений было описано в статье Настройка BGP для обхода блокировок, версия 3, без VPS, которая стала достаточно популярной в сети и породила несколько сотен пользователей сервиса.

Однако "Tempora mutantur et nos mutamur in illis". За прошедшие три года сервис пережил Alpharacks-gate, похоронивший вместе с собой практически все донаты, упирание в технические ограничения как следствие роста количества пользователей, упирание в те же ограничения как следствие взрывного роста количества ip-адресов в списке РКН... Да что только не пережил. Каждое из этих изменений приводило к небольшому устареванию предыдущей статьи и когда неделю назад один из хабраюзеров предложил мне поправить ее под текущие реалии, я понял, что проще родить нового, чем отмыть этого написать новую версию, заодно и ответив на часто задаваемые вопросы. Результат - ниже.

UPDATE: Статья перестала быть актуальной, новую версию читайте здесь.

Зачем всё это делается в принципе и как оно устроено логически — описано в первой и второй статьях.

После их публикации я получил несколько вопросов от людей, которые пользуются VPN с не принадлежащих им ресурсов (например, приобретающих коммерческую услугу VPN). Этим людям раньше я советовал завести VPS для развертывания BGP-сервиса или каким-то еще образом получить доступ к серверу на Linux.

Но с сегодняшнего дня для них (и для всех остальных) есть более удобный вариант — на бесплатном сервисе antifilter.download появилась возможность автоматически настраивать BGP-сессию с вашим маршрутизатором.

0x00 start

; {EN} entry point, do nothing, just run _main {EN}

Статья для начинающих “воинов тьмы”, тех, кто хочет погрузиться в темную сторону силы: реверс-инжиниринг. На нашем “операционном столе” будет небольшой кустарный сервер, который работает по протоколу TCP/IP. Для анализа протокола обмена данными нам поможет стандарт де-факто в области реверса — IDA Pro.

Статей по реверс-инжинирингу и по IDA Pro уже написано немало (хотя и не столько, как по PHP), но поскольку процесс реверса — исследовательский, то мысли, как с "другого боку" подойти к задаче обратной разработки, полезны новичкам. По крайней мере, как автор, я руководствовался тем, чтобы изложить основные практики и техники, о которых говорю в первые дни всем стажерам и на первых парах курса по реверс-инжинирингу в университете.

"Once you start down the dark path, forever will it dominate your destiny".