Как лучше у вас работает gre на ядрах, которые построены поверх ipv6 linux 6.12.67/68?

Проблемы с GRE/IP-туннелями поверх IPv6 на конкретных версиях ядра вполне возможны, особенно если используется Alpine, VPS-виртуализация, offload на virtio/e1000, nftables/iptables и нестандартная MTU. Если после замены ядра проблема ушла, это сильный признак регрессии в связке kernel + сетевой драйвер + туннель, а не ошибки в вашей конфигурации.

Я бы проверял не только GRE, а весь путь: загрузка модуля, MTU, маршруты, firewall, sysctl и encapsulation. Минимальные команды:

uname -a
ip -d link show
ip tunnel show
ip -6 route
lsmod | grep -E 'gre|ip6'
dmesg | grep -i -E 'gre|tunnel|segmentation|mtu|virtio'

Для GRE через IPv6 важно, какой именно тип туннеля используется: ip6gre, gre, sit, gretap. После обновления ядра могли поменяться параметры по умолчанию, обработка checksums или offload. Частый обходной путь — отключить offload на интерфейсе VPS:

ethtool -K eth0 tso off gso off gro off
ethtool -K eth0 tx off rx off

Второй частый источник — MTU. GRE добавляет overhead, IPv6 тоже имеет свои требования. Если пакеты проходят только маленькие или туннель “умирает” после старта, ставьте MTU ниже:

ip link set dev gre1 mtu 1400
# при необходимости 1380 или 1360

На Alpine также стоит проверить, не обновились ли вместе с ядром iptables-nft, nftables, busybox или network scripts. Иногда проблема выглядит как “ядро”, а фактически после reboot применился другой firewall-набор.

Если нужно стабильное решение на проде, я бы закрепил рабочую версию ядра, описал регрессию с выводом uname -a, ip -d link, минимальным конфигом туннеля и отправил баг в Alpine/kernel provider. Для критичного канала GRE лучше не держаться на свежем ядре без теста: сначала staging VPS, затем обновление боевой машины.