Pritunl: состојба на управување наспроти генерираниот профил

Еден архив враќа работно распоредување на Pritunl; другиот враќа само негова слика. Клиентскиот профил, копијата од конфигурацијата на домаќинот и tarball на директориумот на состојбата сите изгледаат како резервни копии и ниту една од нив сама по себе не ги враќа организациите, корисниците и дефинициите на сервери што ги управува Pritunl. Разликата е во сопственоста: дел од состојбата им припаѓа на база на податоци, дел на домаќинот, а дел е регенериран излез. Изберете погрешен слој и враќањето создава сервер што стартува, слуша и не знае ништо. Оваа споредба ги одделува трите слоја, за да одговара архивата што ја чувате на дефектот од кој се враќате.

Два објекти изгледаат како резервни копии и само еден ја враќа услугата

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

Копијата од конфигурацијата на домаќинот е исто толку делумна. /etc/pritunl.conf содржи поставки на ниво на домаќин, вклучително како да се стигне до базата на податоци, и не ги содржи самите VPN објекти.

Што поседува базата на податоци и што поседува домаќинот

Pritunl ги чува дефинициите на сервери, корисниците, организациите и клучевите во MongoDB. Таа база на податоци е авторитетната контролна рамнина и секоја генерирана OpenVPN датотека на дискот е излез изведен од неа. Промена направена директно во генерирана датотека преживува до следното регенерирање и потоа исчезнува, затоа уредувањето на датотеки во време на извршување не е трајно поправање. Истото правило важи за ефективните патеки и интерфејси: тие опишуваат што создала контролната рамнина, а не што треба да создаде.

Домаќинот придонесува со помал, но непренослив збир вредности. Една од нив е /var/lib/pritunl/pritunl.uuid, идентитетот на тој конкретен јазол.

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

Направете конзистентен излез, а не копија на директориум

Копирањето на директориумот со податоци на MongoDB додека услугата пишува создава датотеки што може да не образуваат употреблива база на податоци. Наместо тоа, користете ја поддржаната патека за излез на базата на податоци, извршена против топологијата што навистина ја имате:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

Самостоен домаќин ја поднесува таа едноставна форма. Збирот реплики бара конзистентен момент во времето, а излезот заснован на oplog има барања што обичен излез нема. Поддржаната постапка зависи од вашата верзија и топологија на MongoDB, затоа не изведувајте ја од присуството на директориум со податоци. Архивирајте го слојот на домаќинот покрај излезот, во истото извршување, со истата временска ознака.

Вежбајте го враќањето пред да ви треба

Резервна копија што никој не ја вратил е хипотеза. Изградете ја услугата во изолирана мрежа, вратете го излезот и вратете ги датотеките на домаќинот:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

На крајот, запомнете дека стара слика враќа стари одлуки. Ако администратор деактивирал идентитет откако бил направен излезот, враќањето повторно го активира. Усогласувањето по враќањето припаѓа на постапката, а не на доцната мисла.