Чому 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 створює файл, який виглядає правдоподібно і не робить нічого корисного. Шлюзу з двома стеками потрібно свідомо налаштувати обидва набори.

Остання перевірка: після того як значення збігатимуться, переконайтеся, що для призначення вибирається маршрут тунелю і що зворотний шлях існує. Увімкнене пересилання на інтерфейсі без маршруту — досі чорна діра, і ця помилка з боку клієнта виглядає однаково.