Вашият .ovpn файл може да изпълнява код, а не само да маршрутизира трафик

Повечето хора четат .ovpn файл така, както четат страницата с настройки на рутер: адреси, маршрути, списък с шифри. Частта, която изпълнява код, стои близо до дъното, до директиви, които изглеждат като водопроводна работа, и работи с каквито права вече има клиентът. Това е пролуката, която използва небрежен или злонамерен профил, и това е също пролуката, която три седмици по-късно превръща полезен DNS помощник в проблем за поддръжката. Директивата за събитие, нивото на сигурност и собствеността на файла решават какво може да се случи; съдържанието на скрипта решава какво всъщност се случва. Прочетете и четирите преди да се свържете.

Профил, който стартира помощник, е програма, а не файл с настройки

Директиви като route и dhcp-option описват състояние, което клиентът трябва да установи, и клиентът ги третира като данни. Скриптът up е различен: клиентът го стартира като процес и му дава среда, пълна с подробности за връзката, така че каквото е написал авторът му, се изпълнява с правата на вашия акаунт. На лаптоп, където потребителят е администратор, това е широка врата за файл, пристигнал като прикачен файл или поставен от форумна тема. Разликата не е стилистична, тя е разликата между конфигурация и код.

Митовете, които си струва да оставим, е че профилът може само да пренасочва трафик. Помощник, който изпълнява ip route add, и такъв, който изпълнява curl срещу отдалечен хост, са един и същ механизъм, а профилът изглежда еднакъв отвън. Нищо във вида на файла не ви казва кой от двата имате, затова прегледът трябва да стигне до самия скрипт.

Какво всъщност решава изпълнението и как изглеждат разрешаващите редове

Три неща управляват помощника: директивата за събитие, която го именува, нивото script-security, което го разрешава, и собствената реализация на клиентската платформа. Профил може да поиска кука и пак да не види нищо да се случва, защото мобилен клиент или орязана настолна сглобка може изобщо да не реализира това събитие. По същия начин профил, който иска повече разрешение, отколкото функцията му изисква, ви казва нещо за произхода си. Нивото на разрешение е способност, не одобрение. Разрешаващите редове изглеждат така, като пътят замества вашия.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Ниво 0 отказва външни програми, а ниво 1, по подразбиране, разрешава само вградените изпълними файлове на клиента, така че куката се нуждае от 2 или по-високо; ниво 3 съществува главно за предаване на стари пароли и е добре да се избягва. Профил, доставен с кука, се нуждае и от директивата, и от това ниво, затова един ред близо до дъното на файла заслужава същото внимание като блока със сертификата. Ръководството на OpenVPN изброява нивата на разрешение и формулировката му си струва да се прочете до това, което профилът всъщност иска.

Собственост, път и какво получава помощникът

Профил, на който вярвате, но който сочи към скрипт, който друг акаунт може да пренапише, не е надеждна уредба, защото прегледът от вчера вече не описва какво работи днес. Проверете собственика и режима на помощника и се уверете, че конфигурираният път води до файла, който сте прегледали, а не до име, което нещо друго може да засенчи. Аргументите и средата заслужават същия поглед: клиентът предава подробности за връзката на куката, а помощник, който записва цялата си среда, може да пише удостоверения в тикет за поддръжка. Предпочитайте документирана интеграция от оператора или платформата пред DNS скрипт, копиран от несвързана публикация, защото два мениджъра на резолвери, които се борят за един и същ файл, дават отказ, който изглежда като счупен VPN.

Когато докладвате за неуспешна кука, редактирайте средата, преди да я поставите някъде. Дъмпът, който ви помага да отстранявате грешки, може да носи и токена, който ви удостоверява.

Провали при почистване се появяват след като тунелът изчезне

Помощникът up добавя маршрути и настройки на резолвер, а помощникът down трябва да ги махне отново. Когато куката down липсва, се проваля тихо или никога не се изпълнява, защото клиентът е убит, остатъците надживяват сесията. Тогава трафикът поема път, който никой не е планирал, а имената се решават през резолвер, който е трябвало да бъде премахнат, докато самият тунел изглежда здрав. Тези симптоми идват след прекъсването, затова се обвинява мрежата, а не профилът.

Тествайте демонтажа като отделна стъпка: вдигнете тунела, запишете маршрутите и резолвера, свалете го, после потвърдете, че и двете са изчезнали. Профил, който се свързва чисто, пак може да остави състояние, а нулев код за изход от помощника не доказва, че резолверът е стигнал там, където мислите.

Преглед на помощника и запазване на изход

Прочетете скрипта от начало до край, търсейки три неща: команди, които изискват права, твърдо зададени пътища, които може да не съществуват във вашата система, и всяко мрежово извикване, което прави. После вижте как се проваля, защото помощник, който поглъща грешки, превръща конфигурационна грешка в загадка. Ако не можете в едно изречение да кажете какво прави скриптът и кой може да го промени, не сте готови да го включите. Профил, който иска повече права, отколкото изисква това изречение, е сигналът да спрете.

Пазете последния работещ профил и помощника, към който сочеше, в защитено хранилище, с отбелязани две версии, така че връщането назад да е копие, а не възстановяване в най-лошия възможен момент. Ако помощникът съществува само за дистрибуция или клиентска версия, която вече не се нуждае от него, оттеглете го в конфигурацията, която притежава настройката, вместо да вдигате права, докато грешките спрат. Това е изходът: по-малко движещи се части, не повече разрешения.