OpenVPN при подигнување на Ubuntu: NetworkManager или systemd?

Повеќето водичи го претставуваат изборот како козметички: или дозволете NetworkManager да го крене тунелот, или овозможете примерок на systemd и готово. Двете патеки се разликуваат во една работа што го одредува исходот на машина без екран, и таа нема никаква врска со тоа кој алат е понов. NetworkManager отклучува тајни преку сесија; примерокот на systemd нема сесија што да отклучи. Изберете ја онаа чие ракување со тајни одговара на машината пред вас.

Сѐ друго, од инсталирањето рути до однесувањето при повторно поврзување, произлегува од таа прва одлука.

Приврзокот за клучеви е разликата што никој не ја споменува

Кога NetworkManager поседува VPN профил, лозинката може да живее во приврзокот за клучеви за најава, кој се отклучува кога корисникот ќе се најави. Тоа добро функционира на преносно сметач: лицето е присутно, приврзокот се отвора, тунелот се крева. На сервер што се подига без надзор нема кој да отклучи нешто, затоа профилот чека тајна што никогаш не доаѓа. Врската изгледа конфигурирана и никогаш не се активира.

Примерокот на systemd ја избегнува таа проблема со читање датотека со акредитиви од дискот, што ја прави датотеката она што го штитите. chmod 400 плус сопственост од root е минимумот, а датотеката треба да остане надвор од резервни копии и шаблони на слики што не ги контролирате.

Поврзувањето на VPN со врска не е гаранција за подигнување

Во nm-connection-editor изберете ја жичената или безжичната врска наместо VPN, отворете го јазичето General, штиклирајте ја опцијата за автоматско поврзување со VPN и именувајте го профилот. Потоа NetworkManager го активира VPN како секундарна врска кога примарната ќе достигне поврзана состојба. Тоа е зависност, а не правило на огнениот ѕид. Пакетите сѐ уште можат да излезат во секундите пред тунелот да се крене, а зачуваната тајна што не се отклучува ја остава машината онлајн без него.

Ако барањето е ништо да не излегува без тунелот, кажете го тоа и изградете прекинувач, бидејќи оваа поставка нема да обезбеди еден. Тестирајте и суспензија и продолжување, бидејќи секундарната врска се преоценува на враќањето.

Примерокот на systemd бара име на датотека што се совпаѓа

Ставете го профилот во клиентскиот директориум што го очекува пакетот, на пример /etc/openvpn/client/office.conf, и од внатре упатете на датотеката со акредитиви со auth-user-pass office.cred. Името на примерокот е името на датотеката без наставката, затоа openvpn-client@office ја чита office.conf. Овозможете го со sudo systemctl enable --now openvpn-client@office и потврдете го совпаѓањето со systemctl cat openvpn-client@office наместо да верувате на пример од блог.

Патеките во профилот се решаваат во однос на работниот директориум на единицата, а не на самиот профил, затоа релативна линија ca или auth-user-pass може да не успее при подигнување, иако работи кога ја тестирате рачно. Користете апсолутни патеки за сѐ што единицата мора да најде. Потоа прочитајте journalctl -u openvpn-client@office -b по вистинско подигнување; единица што известува дека е активна без тунел обично именува отсутна датотека во тој дневник.

Понестарите пакети испорачуваат друго име на шаблон, затоа systemctl list-unit-files 'openvpn*' одредува кое постои на овој домаќин.

Однесувањето при повторно поврзување е одделна одлука

Профил со ping-restart го обновува тунелот откако ќе падне, а единица со директива за рестартирање прави нешто слично на ниво на услуга. Тоа се политики што ги избирате, а не стандардни вредности што ги наследувате. Ако врската треба да се крева само по барање, намерно отстранете го однесувањето за рестартирање и запишете зошто. Ако единицата стартува пред мрежата да биде употреблива, ѝ треба политика за повторни обиди, бидејќи еден неуспешен обид при подигнување не се повторува сам.

Запирањето е исто толку буквално: sudo systemctl disable --now openvpn-client@office го запира примерокот што работи и ја отстранува врската за подигнување. Самото оневозможување го остава тунелот да работи до следното рестартирање, што го изненадува секој што тестира со оневозможување и гледа како интерфејсот останува кренат.

Рестартирајте, потоа проверете четири работи по ред

Рестартирањето на услугата ја тестира услугата; рестартирањето на машината ја тестира патеката на подигнување. По рестартирањето потврдете дека единицата се кренала, потоа дека постои рута за оддалечената подмрежа, потоа која адреса машината ѝ ја претставува на интернет, и на крајот дека имињата се решаваат преку тунелот. Тие четири проверки паѓаат токму во тој ред кога нешто не е во ред, што го прави првиот неуспех корисен.

Активна единица без рута обично значи дека профилот се поврзал, но серверот не потиснал ниту една рута, или рутата била инсталирана на интерфејс што подоцна исчезнал. Рута без работно пребарување на имиња упатува на DNS конфигурацијата, а не на самиот тунел.

Одлучете однапред што треба да се случи кога тунелот не може да се крене. Враќањето на обична поврзаност е политика и треба да се запише, наместо да се остави на оној управувач што стартувал прв.