ip: SIOCADDTUNNEL: No such device не могу поднять GRE туннель

А в ядре оно хоть как-то есть?

А что говорит zcat /proc/config.gz | grep IPGRE ?

или lsmod|grep ip_gre

или dmesg|grep ip_gre

[ 456.999200] ip_gre: GRE over IPv4 tunneling driver

Возможно дров не хватает. Там возможно модули какие-то должны быть для tun в ядре.

Виртуалка? В dmesg есть про GRE demultiplexor?

если оно загрузилось, то GRE demultiplexor есть в ядре. Оно от него зависит.

Не, это для tun/tap нужен tun.ko

А «ip tu» что-нибудь говорит ?

В dmesg ругани после «ip_gre: GRE over IPv4 tunneling driver» нет?

А это нормальная система или какой-нибудь контейнер типа openvz ?

В 2.6 были какие-то странности и баги, но они умерли вместе с ядром 2.6 :)

Это не всегда так было, мы же 2.6 обсуждаем. Я точно помню, что в 2.6 GRE мог быть без GRE demultiplexor. Вот патч, реализующий зависимость https://mail.openvswitch.org/pipermail/ovs-dev/2013-June/272696.html для 2.6.37, значит в этой версии ядра и ниже точно demux и gre включались независимо.

А вот объяснение бага ТС, если у него и demux и gre загружены: https://unix.stackexchange.com/questions/107601/gre-supported-in-kernel-but-i... и как-то можно нагуглить и патч для ip_gre.c на этот баг, либо не загружать demux.

Каким образом можно отдельно собрать и добавить исправный модуль ip_gre? А то я так понимаю другим способом это не решится…

Зачем сейчас пытаться исправлять баг в старом ядре, которое вышло 10 лет назад и давно сдохло, при том, что баг давно исправлен в актуальных ядрах?

Я не верю, что ядра 2.6 работают лучше чем 4.4

Если нет железа, которое поддерживается только в ядрах 2.6, то нет смысла оставаться на этих старинных ядрах.

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

Решение есть - пересборка ядра.

Если не ошибаюсь, эти проблемы связаны с появлением поддержки в ядре mppe и еще какой-то фичи для работы accel-ppp

Если можешь пересобрать ядро, то это будет решением проблемы с минимальным изменениями системы.

для сборки нужен старый софт (компилятор не выше gcc-4, старые binutils, make, sed).

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

Почти не ошибаетесь :) Не mppe, а pptp, и не с поддержкой, а с ускорением. Так pptp+mppe стало поддерживаться (на уровне патчей) в 2.4.18 или .16. И accel-pptp, вроде на 2.4 как-то работал, хотя значительно позже, чем 2.4.18. Но ядро не различало разные pptp сессии и в user-space для pptpd валились все приходящие GRE пакеты, каждый процесс сам выбирал нужные ему. Всё работало, но терминировать кучу клиентов на одном сервере быстро не получалось.

demux решил эту проблему, а чистые gre тунели, видимо, был не особо нужены, раз не сразу заметили проблему. Хотя, на момент выхода 2.6.3x уже и pptp то не особо был нужен...

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

Модуль собрать отдельно можно, но, если оригинальных исходников нет и собирать с ванильных, то могут быть проблемы. С одной стороны ядро может быть патчено и модуль не подойдёт. Или ядро вобще может быть собрано с CONFIG_MODULE_SIG_FORCE — не загружать не подписанные модули.