Почему net.ipv4.conf.default.forwarding не трогает tun0

Вы задали net.ipv4.conf.default.forwarding=1, перезапустили VPN, а туннель по-прежнему отбрасывает пакеты, которые шлюз должен маршрутизировать. Настройка в файле выглядит правильно, а интерфейс по-прежнему сообщает, что пересылка отключена. Ничего не сломано: вы изменили значение, которое унаследуют будущие интерфейсы, а не то, которое использует живой туннель.

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

Читайте три значения вместе

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Частый результат — ip_forward = 0, default.forwarding = 1 и tun0.forwarding = 0. Первые два расходятся в вопросе о роли хоста, а третий показывает, что интерфейс делает на самом деле. Такое сочетание соответствует хосту, который никогда не настраивался как маршрутизатор, а получил только значение шаблона. Три числа не противоречат друг другу; они отвечают на три разных вопроса. Запись значения шаблона тоже не решает роль хоста.

Почему двигается именно глобальный переключатель

net.ipv4.ip_forward — это управление для всего шлюза. Его изменение обновляет настройки пересылки для каждого интерфейса в рамках той же операции, поэтому одна запись может заставить существующий туннель начать пересылать. default.forwarding задаёт только интерфейсы, инициализируемые после этого, поэтому туннель, который уже существовал, сохраняет значение, с которым родился.

Документация ядра помечает ip_forward как особый по связанной причине: его изменение сбрасывает набор других параметров IPv4 к значениям по умолчанию для хоста или маршрутизатора. Это делает его грубым инструментом. Задать его один раз в рамках установления роли шлюза — нормально; переключать его снова и снова как приём отладки может тихо перезаписать конфигурацию, на которую вы потратили время.

Значения для каждого интерфейса тоже существуют не зря. Намеренно управляемый шлюз может держать пересылку выключенной на интерфейсе, который никогда не должен маршрутизировать, даже когда хост пересылает в другом месте. Поэтому важно читать живой интерфейс и поэтому одно глобальное значение — не весь ответ. Читайте такое исключение как осознанное решение и запишите, чем этот интерфейс отличается. Иначе следующий инженер услужливо его "починит".

Сделайте настройку постоянной в правильном месте

Успешный однократный sysctl -w доказывает, что ядро принимает значение. Он не переживает перезагрузку и не переживает сетевого менеджера, который при повторном подключении снова применяет своё представление о конфигурации интерфейса. Поместите роль шлюза в конфигурационный файл sysctl или в сетевой менеджер, которому принадлежит хост, а затем перезапустите службу, которая это применяет.

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

Перечитайте те же три значения после переподключения VPN и ещё раз после перезагрузки. Заново созданный туннель — это новый интерфейс, а новый интерфейс берёт значение по умолчанию, действующее в момент создания. Если числа меняются между этими событиями, конфигурацию применяет что-то, что вы ещё не определили.

Не чините это неправильным инструментом

Когда пересылка выглядела сломанной, возникает соблазн очистить межсетевой экран или добавить masquerading. Ни то, ни другое не решает переключатель пересылки. Состояние пересылки, разрешение пересылать, маршрут к назначению и обратный путь — это четыре отдельных требования, и только первое из них — sysctl.

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

Держите случай IPv6 отдельно

Здесь всё про IPv4. Пересылка IPv6, объявления маршрутизатора и поведение accept_ra имеют собственные средства управления, и копирование пути ipv4 в настройку ipv6 создаёт файл, который выглядит правдоподобно и не делает ничего полезного. Шлюзу с двумя стеками нужно осознанно настроить оба набора.

Последняя проверка: после того как значения совпадут, убедитесь, что для назначения выбирается маршрут туннеля и что обратный путь существует. Включённая пересылка на интерфейсе без маршрута — всё ещё чёрная дыра, и эта ошибка со стороны клиента выглядит одинаково.