Зробіть пересилання IPv4 постійним після перезапуску VPN-шлюзу

Пінг шлюзу працює, а доступ до чогось за ним — ні, і це форма проблеми пересилання, а не проблеми тунелю. Локальна доставка до шлюзу доводить, що тунель піднявся і призначення адреси спрацювало; вона нічого не каже про те, чи пропустить ядро пакет з одного інтерфейсу в інший. Перш ніж торкатися будь-якого sysctl, переконайтеся, що машина призначена для маршрутизації цього трафіку і знайдіть мережевий контекст, у якому є інтерфейс, звернений до клієнта. Потім читайте значення там, а не там, куди випадково зазирнув останній прочитаний посібник.

Досягти шлюзу — не те саме, що пересилати

Усередині ядра ухвалюються два окремі рішення. Доставка на локальну адресу завершує подорож пакета; пересилання знову відправляє його назовні через інший інтерфейс, і цим другим рішенням керують для кожного мережевого простору імен. Шлюз може бути цілком доступним, коли пересилання вимкнене, і з командного рядка ping обидві несправності виглядають однаково.

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

Читайте значення там, де пакети справді є

На шлюзі, який маршрутизує в просторі імен хоста, на питання відповідає одна команда: sysctl net.ipv4.ip_forward. Коли вхідний і подальший шляхи живуть у названому просторі імен, запитайте той простір: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Значення хоста не замінює значення простору імен, і одиниця на хості нічого не доводить.

Не кожен контекст маршрутизації має мітку, яку можна передати команді ip netns. Середовища виконання контейнерів і служби створюють простори імен, які ніколи не реєструються під дружнім ім'ям, і для них використовують інструменти перевірки середовища. Замініть vpn-gw на справжнє ім'я або на механізм середовища, що досягає того самого контексту, і припиніть вгадувати на рівні хоста.

Дайте налаштуванню одного власника

На звичайному хостовому шлюзі з systemd постійною формою є drop-in-файл з обраним адміністратором ім'ям, наприклад /etc/sysctl.d/60-vpn-forwarding.conf, що містить net.ipv4.ip_forward = 1. Запишіть файл, потім завантажте саме цей файл, щоб змінився і поточний стан: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, після чого прочитайте значення назад. Ім'я файлу — приклад, а не зарезервований шлях VPN, і провідне число важливе, бо файли, відсортовані пізніше, перемагають.

Пріоритет — це місце, де постійність тихо ламається. Перевірте і завантажувач дистрибутива, і свій drop-in, бо procps sysctl --system у кінці також читає /etc/sysctl.conf, тоді як порядок sysctl.d у systemd — зовсім інша послідовність. Пізніше призначення може одразу повернути той самий ключ, залишивши ваш файл правильним, а дійсне значення — неправильним. Не перезаписуйте наявний адміністраторський файл, щоб виграти цю суперечку; знайдіть власника і змініть там.

Простір імен, створений після завантаження, взагалі не керується хостовим drop-in. Його налаштування належить тому, що його створює: середовищу виконання контейнерів або модулю підготовки простору імен. Давати контейнеру широкі права хоста, щоб обійти питання, — гірша угода, ніж витратити десять хвилин на пошук правильного власника.

Знайте, скільки коштує перемикач, перш ніж його перемикати

ip_forward не безпечний boolean. Документація ядра зазначає, що його зміна скидає кілька інших параметрів IPv4 до типових значень хоста або маршрутизатора, тому діагностичне перемикання може викинути налаштування, зроблене в іншому місці, і навіть не згадати про це. Ставтеся до нього як до зміни конфігурації з побічними ефектами, а не як до перевірки, яку можна виконати недбало.

Це також виключає вимикання й увімкнення щоразу, коли клієнт не може досягти хоста. Якщо значення вже одиниця, несправність в іншому місці шляху, і третій перезапис того самого ключа його не зрушить.

Доведіть постійність, потім перевірте решту шляху

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

Увімкнене пересилання все ще залишає три речі для перевірки. Клієнту потрібен маршрут до призначення, шлюзу — подальший маршрут плюс дозвіл ним користуватися, а призначенню — зворотний шлях до адреси клієнтського тунелю. Приватна маршрутизована LAN не потребує NAT автоматично, тому не додавайте masquerading, поки не дізнаєтеся, якої з трьох речей бракує, і перевіряйте з передбачуваного клієнта, а не з самого шлюзу, бо запит, що виник на шлюзі, ніколи не торкається шляху пересилання, який ви щойно ввімкнули. IPv6 має власну політику пересилання й маршрутизації, тому робоча перевірка IPv4 нічого про неї не каже.

Тримайте разом у runbook шлях drop-in, власника простору імен і команду зворотного читання. Той, хто візьме це далі, має вміти прочитати значення, побачити, кому воно належить, і протягом хвилини вирішити, чи проблема в постійності, чи в решті шляху.