ifconfig-noexec няма да спаси SSH сесията ви: какво прави
Той потиска собствената настройка на адреса на интерфейса от OpenVPN. Не запазва маршрут за отговор по SSH, не изключва всяка промяна на маршрути и не доставя липсващия адрес.
Някъде в тема във форум ifconfig-noexec се предлага като поправка, която запазва SSH сесията жива, когато тунелът се вдигне. Разсъждението звучи правдоподобно, докато не проверите какво засяга опцията. Тя спира OpenVPN да конфигурира адреса на тунелния интерфейс и вместо това предава тези стойности на скриптове; за това къде отиват отговорите на управляващата ви връзка не казва нищо. Ако вярвате на друго, получавате тунел без използваем адрес и SSH сесия, която все още умира.
Какво всъщност делегира опцията
По подразбиране клиентът вдига тунелното устройство и задава локалния и отдалечения адрес, които сървърът му е дал. С зададена ifconfig-noexec тази стъпка се прескача и договорените стойности се експортират в средата на скрипта, за да ги приложи нещо друго.
Собствеността се мести. На нейно място не се измисля нищо.
Значи въпросът, на който опцията отговаря, е кой конфигурира интерфейса, а въпросът, на който не отговаря, е как пакетите намират пътя обратно до вас. Дръжте тези две неща отделно, иначе ще прекарате вечер в редактиране на маршрути, за да компенсирате интерфейс без адрес.
Три подобни опции с различни задачи
Това семейство лесно се бърка, защото имената се различават с една дума, а симптомите се припокриват. Прочетете какво потиска всяка от тях, преди да изберете някоя.
| Опция | Какво спира да се случва |
|---|---|
ifconfig-noexec | Собствената настройка на тунелния адрес от OpenVPN; стойностите вместо това отиват в скриптове |
route-noexec | Автоматично добавяне и премахване на маршрути; подробностите за маршрута отиват в скрипт |
route-nopull | Изтласканите от сървъра маршрути и свързаните опции като DNS се отхвърлят |
Това са алтернативи за разбиране поотделно, а не набор за слепване. Потискането на настройката на адреса не потиска промените на маршрути, правилата на защитната стена или изтласканите опции, които носят DNS. Делегираният скрипт също е свободен да променя маршрути и това е решение, което предавате, вместо да избягвате.
Ако клиент на доставчик обвива двигателя, използвайте поддържаната му интеграция, вместо да пускате директива на ниско ниво в профил и да се надявате, че обвивката ще я уважи. Обвивките често пресъздават профила при свързване, така че ръчната промяна изчезва без грешка. Проверете къде клиентът пази настройките си, преди да прекарате вечер над файла. Това важи за всеки ред в таблицата, не само за реда, за който сте дошли.
SSH сесията, която сте искали да защитите
Една SSH връзка има адрес на източника, адрес на местоназначението и път за отговор. На сървър, който току-що е инсталирал пълнотунелен маршрут по подразбиране, отговорът към публичния ви адрес съвпада с тунела и VPN шлюзът го изхвърля.
Нищо в настройката на адреса на тунелния интерфейс не променя това.
Това се оправя с по-конкретен маршрут за адреса ви за управление през шлюза преди тунела, или с правило за политика, което насочва този трафик, плюс настройките за филтриране, които прилага хостът ви. Двата проблема понякога се появяват заедно и точно така единият се взема за лек срещу другия. Тествайте ги поотделно: вдигнете тунела без опцията, погледнете адреса на интерфейса и пътя за отговор, после решете кой от двата всъщност е счупен.
Какво трябва да поеме делегираният скрипт
Ако наистина искате друг собственик да конфигурира интерфейса, избройте работата: приложете локалния и отдалечения адрес, вдигнете устройството, възстановете или премахнете адресирането при разглобяване и направете същото отново след повторно свързване. Стойностите от една успешна сесия не бива да се втвърдяват, защото сървърът може да даде друга двойка следващия път.
Променливите на средата, които клиентът експортира, са единственият поддържан вход за тази работа.
env | grep -E '^ifconfig_|^route_'Вътре в скрипт route-up тези променливи са налични; от задача на cron или ръчна обвивка не са. Потвърдете кой hook от жизнения цикъл използва вашата версия и че hook-ът се изпълнява с достатъчно права да промени интерфейса, тъй като клиентът може вече да е слязъл до непривилегирован потребител.
Тествайте целия жизнен цикъл, а не една сесия
Вдигнете тунела, проверете адреса на устройството, после се свържете отново и го проверете пак. Конфигурация, която работи веднъж и се проваля при втория опит, обикновено означава, че делегираната стъпка се изпълнява само при първото свързване.
После тествайте двата критерия за приемане заедно: нова SSH връзка по предвидения път за управление работи и разрешено приложение използва тунела правилно.
Стара SSH сесия, която случайно оцелява, докато тунелът е без адрес, не е успех и това е точно състоянието, което тази опция създава, когато никой не поеме работата. Проверете първо адреса на интерфейса, после пътя за отговор при управлението, после приложението. Ако две от трите са грешни, опцията е преместила работа, без да ѝ даде собственик.