Ненадгледана ажурирања VPN сервера захтевају проверен пут опоравка
Ажурирање може поново да покрене управо ону услугу преко које долазите до сервера. Упоредите ванпојасну конзолу са планом опоравка само преко тунела пре него што аутоматизујете.
Ненадгледана ажурирања су разумна политика за сервер коме приступате преко његовог сопственог VPN-а и истовремено су једна тачка самонанете штете. Операција пакета поново покреће услугу, тунел пада и административни пут који сте користили нестаје заједно са њим. Постоје два модела опоравка, а избор између њих зависи од једног услова: да ли имате пут приступа који не пролази кроз оно што се ажурира.
Два модела опоравка, један одлучујући услов
Први модел верује ажурирању и претпоставља да ћете после моћи поново да се повежете. Делује када је VPN један од неколико начина да дођете до хоста и када квар тунела не уклања вашу могућност да га дијагностикујете. Други модел унапред поставља независан пут, обично конзолу провајдера хостинга, и третира тунел као оно што ће одржавање највероватније покварити. Оба модела су одбрањива, а само један од њих захтева рад унапред.
Одлучујући услов је лако изговорити и лако прескочити. Ако сваки административни пут до машине иде кроз услугу која се ажурира, немате никакав модел опоравка, само очекивање. Реците то наглас у прегледу промене.
Провера тог услова траје десет минута и мора да се догоди пре првог ненадгледаног ажурирања, а не током инцидента. Отворите конзолу док све ради, потврдите да су акредитиви актуелни и затворите је поново. Потврдите да се конзола отвара на хосту на који мислите. Затим потврдите да пријава коју бисте заиста користили у 3 сата ујутру још ради.
Последњи део је важнији него што звучи. Конзолни налог чија је лозинка ротирана пре шест месеци и никада проверена није пут опоравка; то је документ који описује такав пут.
Шта сигурносна копија не враћа
Архива конфигурације је запис о датотекама, а ажурирање мења више од датотека. Стање пакета, кернел модули, омогућене везе unit-а и правила заштитног зида примењена засебним алатом живе изван конфигурационог директоријума, а враћање које их занемари производи машину која изгледа конфигурисано и не прослеђује саобраћај.
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
Ауторизација заслужује свој ред. Копија направљена пре уклањања компромитованог уређаја радо ће вратити приступ тог уређаја. Враћање на њу током прекида је начин да један инцидент постане два, а одлука о враћању треба да се донесе о peer-овима једнако експлицитно као о датотекама.
Механизам враћања је такође важан. Копирање старије извршне датотеке преко оне којом управља пакет није подржано поништавање промене пакета и оставља базу пакета да описује стање с којим се датотечни систем не поклапа. Користите сопствени пут за downgrade управника пакета или снимку коју нуди провајдер. Downgrade који база пакета забележи је онај који можете поновити.
Ништа од овога не говори против сигурносних копија. Говори у прилог томе да знате који слој покрива сваки артефакт, јер је начин квара делимичног враћања збуњујући више од изворног прекида. Упишите слој уз сваку копију у runbook.
Контролна тачка, ажурирање, па провера споља
Забележите стање пре промене у облику који можете касније да упоредите: инсталиране верзије, укључене сервисне unit-е, socket-е који слушају и тренутни списак peer-ова. Четири наредбе покривају већину тога на Linux хосту.
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'Прва показује које unit-е постоје и раде ли, друга потврђује да је слушалац заиста везан, а трећа вам даје сопствени извештај услуге о последњих неколико минута. Ниједна од њих не доказује да клијент може да се повеже, зато се следећи корак одвија изван хоста. Сачувајте та очитавања као своју основу за поређење.
Проверите са мреже која не користи тунел: аутентификујте једног овлашћеног клијента, разрешите име и досегните једну предвиђену апликацију. Локална статусна линија која каже да је интерфејс подигнут изјава је о интерфејсу, не о рутирању, кључевима или политици која прима peer.
Затим намерно испитајте пут поновног повезивања. Поново покрените услугу једном и потврдите да се тунел враћа без ручне интервенције, јер услуга која исправно стартује само при подизању система је услуга која ће вас изненадити у најгорем тренутку.
Када не успе, користите пут који сте испитали
След опоравка није гламурозан и делује: дођите до хоста независним путем, прочитајте сопствене логове услуге и вратите конкретну контролну тачку која одговара квару. Мењајте једну ствар по покушају да би следеће читање лога нешто значило.
Одуприте се пориву да направите неколико незабележених промена како бисте вратили повезаност. Машина поправљена са пет истовремених измена не може се после објаснити, а следеће ажурирање поново ће увести ону која је заиста носила оптерећење.
Затим одлучите трајну политику с доказима. Ако је ажурирање открило зависност коју нико није документовао, поправка је документација и тест, а не искључивање ажурирања. Ако је открило услугу која не може чисто поново да се покрене, поправка је у unit-у, а не у распореду.
Поређење се чисто решава када се услов именује. Независан пут чини ненадгледана ажурирања управљивим ризиком. Његово одсуство чини исту политику планираним прекидом с непознатим временом опоравка, и никаква количина аутоматизације не мења ту аритметику.