Чому попередження vpnc про скидання маршрутів з'являється в контейнері

Свіжі журнали контейнера часто закінчуються скаргою Read-only file system на /proc/sys/net/ipv4/route/flush, і цей рядок звинувачують у проблемах тунелю, який може бути цілком справним. Запис за ним адресований запису ядра, який більше не робить нічого корисного, оскільки кеш маршрутів IPv4 зник. Усередині контейнера /proc/sys монтується лише для читання, тому перенаправлення відхиляється до того, як потрапить хоч якесь значення, і оболонка друкує цю відмову. Робочий тунель може друкувати це попередження, поки старий рядок залишається у скрипті, і --privileged ніколи не робить запис осмисленим.

Що скрипт намагався скинути

Старі скрипти підключення закінчувалися очищенням кешу: записати значення в керівний файл ядра й попросити стек IPv4 скинути свій кеш маршрутизації, щоб новий маршрут тунелю вибирався, не чекаючи завершення терміну застарілих записів. Файл адресувався в /proc/sys/net/ipv4/, що робило операцію перенаправленням оболонки, а не командою маршрутизації. Ядро 3.6 видалило цей кеш, а разом із ним і причину існування скидання. Ніщо в поточному шляху даних не залежить від цього запису.

Сам запис зберігся як застарілий файл лише для запису, тому скрипт, який досі пише в нього, досягає реального шляху й реальної перевірки прав. На хості запис повертає успіх і нічого не змінює. У контейнері те саме перенаправлення натрапляє на /proc/sys лише для читання й завершується з EROFS, який оболонка друкує як повідомлення файлової системи лише для читання. На ядрах, де шлях справді відсутній, формулювання стає No such file or directory, і висновок не змінюється.

Дві помилки кажуть про різне, і різницю варто тримати ясною. Read-only file system означає, що ядро дійшло до запису й відмовило в записі; No such file or directory означає, що запису більше немає. Жодне повідомлення не повідомляє про пристрій тунелю, маршрути чи розв'язання імен, тож жодне не може виправдати більше привілеїв.

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

Перевірте монтування й маршрут, перш ніж додавати привілеї

Три перевірки відділяють косметичне попередження від справжнього збою: чи несе встановлений скрипт цей рядок, як змонтовано /proc/sys і куди насправді йде трафік застосунку. Виконуйте їх у тому самому просторі імен контейнера або на хості, де з'явилося попередження, бо перевірка на сторонній машині відповідає на інше питання.

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

Відповідь grep слабша, ніж здається, бо знахідка доводить наявність рядка, а не те, що він виконується без захисту; підтримуваний скрипт може тримати запис усередині перевірки, яка його пропускає. findmnt -no OPTIONS /proc/sys прямо вирішує питання монтування, а ro у цьому виводі означає, що будь-який запис нижче цієї точки відхиляється, що б не робив скрипт. Далі пошук маршруту показує, чи розв'язується потрібна застосунку адреса через інтерфейс тунелю чи через шлюз контейнера за замовчуванням. Пошук, що вибирає шлюз за замовчуванням, означає, що тунель піднявся й нічого в нього не маршрутизується, а це проблема маршрутизації, а не привілеїв.

Звідки насправді береться виправлення

Підтримуване виправлення живе у скрипті, а не в прапорцях контейнера. upstream vpnc-script змінив обробку цієї операції, тож порівняйте копію в образі з поточним upstream і оновіть через пакет або збирання образу, якe її постачає. Файл, відредагований вручну в робочому контейнері, не підлягає перевірці й не переживе наступного збирання.

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