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 | #совет

Claude снова банит пользователей из РФ

Многим начали приходить письма счастья от Anthropic: аккаунт заблокирован, доступ закрыт. Банят за вход из неподдерживаемого региона и оплату через серые схемы.

А в CatCode Claude работает без ограничений.

CatСode - это десктопный агент с топовыми нейросетями на борту всего за 1550 рублей в месяц:

😒 Claude Fable
🤖 GPT-6 Astra
😐 Grok 4.6
и многие другие.

Твой аккаунт точно не забанят: подписка оформлена у международной компании. Работает без VPN, оплата российской картой или СБП, никаких перекупов. Первые задачи бесплатно, просто зарегистрируйся и пробуй.

Оформи пакет нейросетей разом и не бойся банов: catcode.dev

Диагностика и настройка 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 | #практика