Хто володіє адресою, маршрутом, DNS і міжмережевим екраном у Linux VPN?

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

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

Пристрій та його адреси

Тунельний пристрій створює або менеджер, який знає профіль, або демон, який хтось запустив вручну. Обидві схеми працюють окремо; їх змішування — ні. Якщо профілем володіє NetworkManager, нехай він володіє і пристроєм, і не запускайте некерований OpenVPN процес проти тієї самої назви тунелю.

Запишіть, хто видаляє пристрій, коли сеанс закінчується. Пристрій, який переживає свій сеанс, — найчастіше джерело застарілих адрес і наступної за ними плутанини.

Маршрути й правила політики

Саме на маршрутах конфлікти володіння завдають видимої шкоди. Менеджер з'єднань встановлює маршрут за замовчуванням для тунелю плюс конкретніший маршрут для віддаленої мережі; потім написаний вручну скрипт додає власний маршрут за замовчуванням з іншою метрикою і тихо виграє або програє залежно від моменту. Вирішіть, які записи прив'язані до з'єднання, які є постійною політикою і який компонент оновлює їх після повторного підключення. Потім тримайте інші компоненти поза цією таблицею.

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

DNS завжди окремий власник

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

Міф тут у тому, що запис сервера імен у профіль змінює, куди йдуть запити. Він змінює те, що повідомляють розв'язувачу, а не сокет, який розв'язувач використовує вище за течією. Перевіряйте запитом і пошуком маршруту замість довіри файлу.

Стан міжмережевого екрана і хто його відновлює

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

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

Життєвий цикл: завантаження, повторне підключення, розбирання

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

Для спостереження ip monitor link address route показує зміни ядра в міру їх появи, але повідомляє про події, а не про намір: видалений маршрут нічого не каже про те, який процес його видалив. Зіставте це з картою володіння, і заплутане завершення роботи перетвориться на короткий список кандидатів.

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