GNU Make умеет специально ломать привычный порядок сборки, чтобы находить ошибки в зависимостях Makefile!

Бывает, что make -j работает нормально, а затем сборка случайно падает на CI или новой машине. Частая причина — одна цель неявно рассчитывает, что другая успеет выполниться раньше, хотя эта зависимость нигде не объявлена.

В GNU Make 4.4 для поиска таких проблем появился --shuffle:

make -j8 --shuffle

Make сохраняет зависимости между целями, но намеренно меняет допустимый порядок их выполнения. Если Makefile случайно зависит от привычной последовательности, вероятность воспроизвести проблему резко возрастает.

Полезно прогнать сборку несколько раз:

for i in {1..20}; do
  make clean
  make -j8 --shuffle || break
done

Если сборка упала, Make сообщает seed перемешивания. Его можно передать повторно и воспроизвести тот же порядок:

make -j8 --shuffle=123456789

Интересно, что --shuffle полезен даже без параллельной сборки:

make -j1 --shuffle

Так можно обнаружить зависимости от порядка выполнения отдельно от настоящих проблем конкурентного выполнения.

🔥 make --shuffle превращает порядок сборки в fuzz-тест: отличный способ найти отсутствующие зависимости в Makefile до того, как они проявятся случайным падением на CI.

🚪 Linux Ready | #совет

Диагностика и настройка MTU в WireGuard VPN

При некорректном MTU туннель WireGuard может оставаться активным, ICMP и SSH работают, но HTTPS-запросы зависают, а передача больших файлов прерывается. Одна из возможных причин — нарушение Path MTU Discovery (PMTUD), препятствующее определению допустимого размера пакетов на маршруте.

WireGuard инкапсулирует IP-пакеты в UDP. Накладные расходы составляют 60 байт поверх IPv4 и 80 байт поверх IPv6 без дополнительной инкапсуляции. При внешнем Path MTU 1500 максимальный MTU туннеля без фрагментации составляет соответственно 1440 и 1420 байт.

Проверим текущий MTU интерфейса WireGuard.

ip link show dev wg0

В типичной конфигурации wg-quick можно увидеть MTU 1420, однако фактическое значение зависит от маршрутизации и настроек интерфейса.

wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420

Проверим прохождение внутренних IPv4-пакетов с установленным флагом DF. Размер ICMP-данных 1392 байта вместе с IPv4- и ICMP-заголовками формирует пакет размером 1420 байт.

ping -4 -M do -s 1392 -c 4 10.20.0.1

Здесь 10.20.0.1 — пример адреса удалённого WireGuard-пира. Успешный ping до него не гарантирует отсутствие ограничений MTU на дальнейшем маршруте.

Если пакеты не проходят, повторим проверку с размером 1340 байт. Ошибка message too long указывает на превышение MTU, известного локальному сетевому стеку, а отсутствие ответа может быть связано с фильтрацией ICMP:

ping -4 -M do -s 1312 -c 4 10.20.0.1

Если HTTPS-сервис находится за удалённым пиром, дополнительно проверим маршрут до его IPv4-адреса и прохождение пакетов, если сервис отвечает на ICMP.

ip -4 route get 10.20.0.10
ping -4 -M do -s 1392 -c 4 10.20.0.10

Здесь 10.20.0.10 — пример адреса целевого сервиса. Маршрут должен проходить через wg0.

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

sudo ip link set dev wg0 mtu 1380

Повторим проверку с ICMP-данными размером 1352 байта, что соответствует внутреннему IPv4-пакету размером 1380 байт.

ping -4 -M do -s 1352 -c 4 10.20.0.1

При необходимости проверим конечный адрес сервиса. Изменение MTU только на одной стороне туннеля не гарантирует устранения проблем в обратном направлении.

После изменения MTU проверим прикладной трафик через VPN. Используем доступный через туннель HTTPS-сервис.

curl -4 -v --connect-timeout 5 --max-time 30 https://INTERNAL_HOST/

Заменим INTERNAL_HOST на реальное имя сервиса и убедимся, что его IPv4-адрес маршрутизируется через VPN.

Если изменение устранило проблему, закрепим значение в существующей конфигурации /etc/wireguard/wg0.conf. Параметр MTU обрабатывается утилитой wg-quick, а не протоколом WireGuard.

[Interface]
Address = 10.20.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
MTU = 1380

Это пример секции [Interface]. Сохраним существующие ключи, адреса и остальные параметры конфигурации.

Значение MTU уже применено командой ip link set, поэтому перезапуск сейчас не требуется. Для проверки сохранённой конфигурации после повторного поднятия интерфейса можно выполнить:

sudo wg-quick down wg0 && sudo wg-quick up wg0

При удалённом подключении через туннель команда может привести к потере доступа. Успешный ICMP-тест не гарантирует корректную работу TCP. При сохранении проблемы проверьте MTU на обеих сторонах туннеля, PMTUD и маршрутизацию.

🔥 Активный WireGuard-туннель не гарантирует передачу крупных пакетов. Проверка DF-пакетов и снижение MTU помогают выявить проблему.

🚪 Linux Ready | #практика

Как проверить TLS-сертификат сервера через OpenSSL?

При подключении к HTTPS-сервису можно получить ошибку проверки сертификата, хотя сам сервер доступен и TCP-соединение устанавливается. Причина может быть в сроке действия сертификата, неправильной цепочке доверия или несовпадении имени сервера.

Для диагностики достаточно стандартной утилиты openssl. Начнём с TLS-подключения:

openssl s_client \
  -connect example.com:443 \
  -servername example.com

Параметр -servername передаёт имя сервера через SNI. Это важно, если на одном IP-адресе размещено несколько HTTPS-сайтов с разными сертификатами.

Посмотреть только основные сведения о сертификате:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

В выводе будут указаны владелец сертификата, удостоверяющий центр и период действия.

Проверим имена, на которые выпущен сертификат:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
openssl x509 -noout -ext subjectAltName

Для проверки доменного имени используется расширение Subject Alternative Name. Наличие подходящего Common Name само по себе не заменяет корректную проверку SAN современными TLS-клиентами.

Теперь проверим не только сертификат, но и цепочку доверия:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error </dev/null

-verify_hostname проверяет соответствие сертификата имени сервера, а -verify_return_error заставляет завершить проверку с ошибкой при обнаружении проблемы в цепочке.

При успешной проверке можно увидеть:

Verification: OK
Verify return code: 0 (ok)

Если сервер не передаёт промежуточный сертификат, клиент может сообщить об ошибке построения цепочки доверия.

Посмотреть все сертификаты, которые сервер отправляет во время TLS handshake:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts </dev/null

-showcerts показывает сертификаты, переданные сервером, а не обязательно полную доверенную цепочку до корневого CA.

Проверим, не истекает ли сертификат в ближайшие 30 дней:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
openssl x509 -checkend 2592000 -noout

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

Если нужно проверить новый сервер до изменения DNS, можно подключиться напрямую к его IP, сохранив SNI:

openssl s_client \
  -connect 192.0.2.10:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error </dev/null

Это позволяет проверить сертификат конкретного узла, не изменяя /etc/hosts и DNS-записи. Отдельно можно проверить согласование TLS 1.3:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -tls1_3 </dev/null

Если соединение не устанавливается, это не обязательно проблема сертификата: сервер может не поддерживать TLS 1.3 или соединение может блокироваться на другом уровне.

🔥 openssl s_client позволяет проверить TLS handshake, SNI, цепочку сертификатов, соответствие hostname и срок действия сертификата. При диагностике HTTPS важно проверять не только даты сертификата, но и корректность всей цепочки доверия — действующий сертификат сам по себе ещё не гарантирует успешную TLS-аутентификацию.

🚪 Linux Ready | #практика

📂 Шпаргалка по работе SSH в Linux!

Например, при подключении через ssh клиент и сервер обмениваются ключами, устанавливают защищённое соединение и проверяют подлинность друг друга.

На картинке — 20 этапов работы SSH: от установки TCP-соединения и проверки known_hosts до аутентификации по ключам и передачи зашифрованных данных.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Знали, что в Linux можно отключить программе доступ к сети без настройки firewall и изменения её кода?

Для этого есть unshare — утилита, которая создаёт отдельные пространства имён ядра. С флагом --net процесс получает собственный сетевой стек, изолированный от сети хоста.

Например, можно проверить, как приложение ведёт себя без сети:

sudo unshare --net -- ./myapp

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

Можно открыть отдельную оболочку и исследовать окружение:

sudo unshare --net -- bash
ip addr
ip route

По умолчанию даже интерфейс lo в новом пространстве имён не поднят.

Если нужен локальный сетевой обмен внутри него, включите loopback:

sudo unshare --net -- ip link set lo up

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

🔥 unshare --net позволяет за секунды воспроизвести отсутствие сети при тестировании приложений, не отключая интернет на всей машине. Особенно полезно для проверки автономного режима, обработки сетевых ошибок и неожиданных внешних зависимостей.

🚪 Linux Ready | #совет

🧐 Base of Knowledge — большая русскоязычная коллекция заметок, шпаргалок и руководств!

В репозитории собраны материалы по Linux, Git, сетям, информационной безопасности, программированию, базам данных и инструментам искусственного интеллекта. Особенно интересно, что здесь есть не только теория, но и разборы конкретных инструментов, полезные команды, инструкции по настройке и решения задач.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

🤔 Крутая статья попалась на Хабре: «Как ускорить дисковую подсистему с помощью bcachefs»!

В этой статье:
• Узнаете, как объединить быстрый SSD и медленный диск с помощью кэширования в bcachefs;
• Разберёте настройку Write Back и проверку производительности через fio;
• Посмотрите на реальные тесты RocksDB, где кэширование ускорило запись в 3,75 раза, а случайное чтение — в 7,74 раза.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

Как запустить процесс в отдельном сетевом пространстве Linux?

Иногда требуется проверить работу приложения в изолированном сетевом окружении, не изменяя маршруты, IP-адреса и правила firewall основной системы. Например, запустить сервис без доступа к внешней сети или проверить, как приложение ведёт себя при отсутствии сетевого подключения.

В линукс для этого предусмотрены network namespaces. Каждый такой namespace имеет собственные сетевые интерфейсы, таблицы маршрутизации, сокеты и ряд других сетевых настроек.

Создадим отдельное сетевое пространство:

sudo ip netns add isolated

Проверим список:

ip netns list

В выводе появится:

isolated

Теперь посмотрим сетевые интерфейсы внутри нового namespace:

sudo ip netns exec isolated ip addr

По умолчанию в нём будет только интерфейс lo, который изначально находится в состоянии DOWN.

Включим loopback:

sudo ip netns exec isolated ip link set lo up

После этого проверим его адрес:

sudo ip netns exec isolated ip addr show lo

На интерфейсе обычно уже назначен стандартный адрес 127.0.0.1/8. Включение lo позволяет использовать его для локального сетевого взаимодействия.

Попробуем выполнить запрос во внешнюю сеть:

sudo ip netns exec isolated \
  ping -c 3 1.1.1.1

Соединение не установится, поскольку в новом namespace отсутствуют внешний сетевой интерфейс и маршрут до указанного адреса. При этом сетевая конфигурация основной системы останется без изменений.

Теперь запустим внутри namespace простой HTTP-сервер. Чтобы не раздавать файлы текущего каталога, создадим отдельный пустой каталог:

mkdir -p /tmp/netns-http

Запустим сервер:

sudo ip netns exec isolated \
  python3 -m http.server 8080 \
  --bind 127.0.0.1 \
  --directory /tmp/netns-http

В другом терминале проверим, что сервер отвечает:

sudo ip netns exec isolated \
  curl -i http://127.0.0.1:8080

Сервер вернёт HTTP-ответ, поскольку клиент и сервер используют одно сетевое пространство. Для пустого каталога это будет страница со списком файлов.

Но если выполнить аналогичный запрос из основной системы:

curl http://127.0.0.1:8080

Подключиться к серверу внутри isolated не получится, если в основном namespace нет собственного listener на этом адресе и порту. Причина в том, что loopback-интерфейсы разных network namespaces независимы друг от друга.

Это позволяет запускать приложения на одинаковых адресах и портах без конфликтов между сетевыми пространствами. Проверим прослушивающие TCP-порты внутри namespace:

sudo ip netns exec isolated ss -tlnp

В выводе будет присутствовать HTTP-сервер, прослушивающий 127.0.0.1:8080.

При этом обычная команда в основной системе:

sudo ss -tlnp

Не покажет этот listener, поскольку ss просматривает сокеты текущего сетевого пространства.

Посмотрим процессы, использующие созданный namespace как основное сетевое пространство:

sudo ip netns pids isolated

Команда выведет их PID, включая процесс HTTP-сервера.

Также можно проверить сетевое пространство конкретного процесса. Подставим PID сервера из предыдущего вывода:

sudo readlink /proc/<PID>/ns/net

В результате получим идентификатор вида:

net:[4026532456]

Число в квадратных скобках идентифицирует объект namespace. У процессов в одном network namespace ссылки /proc/<PID>/ns/net указывают на один и тот же объект.

Для удаления окружения сначала остановим HTTP-сервер через Ctrl+C, затем удалим namespace:

sudo ip netns del isolated

🔥 Удаление имени namespace не завершает автоматически процессы, которые его используют. Само сетевое пространство сохраняется, пока на него существуют ссылки.

🚪 Linux Ready | #практика