Клиентска кука или сървърна кука? Къде се изпълнява скрипт на 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; платформата, на която разгръщате, документира дали изобщо ги предоставя. Скрипт, който успява в интерактивен администраторски терминал, е хипотеза, а не проверка.