Клієнтський хук чи серверний хук? Де виконується скрипт OpenVPN

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

Дві машини, два питання, на які треба відповісти спершу

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

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

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

Серверний варіант: подія на кожне підключення

Скрипт client-connect виконується в контексті процесу сервера, коли підключається автентифікований клієнт, і отримує задокументовані відомості про з'єднання, як-от common name і виділену адресу. Це правильне місце, щоб записати фрагмент конфігурації для клієнта, застосувати політичне рішення або зафіксувати стан, яким володіє сервер.

Різниця, яку люди пропускають, — це різниця між цим хуком і серверним хуком up. Хук up спрацьовує, коли сервер відкриває свій тунельний пристрій, а на сервері з кількома клієнтами це відбувається один раз під час запуску демона. Це не подія на кожен вхід, і код, розміщений там, виконується під час запуску служби, а не коли підключаються користувачі.

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

Клієнтський варіант: робота, яка має виконуватися локально

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

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

Назви теж важливі. Хук up відповідає створенню пристрою, а route-up — встановленню маршрутів, але завдання, якому потрібна доступна приватна мережа, має перевіряти доступність, а не припускати, що створення пристрою означає готовність кожного маршруту, запису resolver і застосунку.

Чому проштовхування виконуваного коду не серед опцій

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

Увімкнення виконання скриптів локально цього не змінює. Ваше налаштування script-security дозволяє локальні скрипти, які обрали ви; воно не дає серверу права постачати нові.

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

Що перевірити, перш ніж довіряти будь-якому з хуків

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

Перевіряйте під тим обліковим записом, який справді його виконає, у той момент, коли він справді виконуватиметься. Посібник openvpn(8) описує обидві родини хуків і обмеження push; платформа, на якій ви розгортаєте, описує, чи надає вона їх узагалі. Скрипт, успішний в інтерактивному терміналі адміністратора, — це гіпотеза, а не перевірка.