Ansible ütleb, et käivitus, aga WireGuard töötab ikka vana konfiguratsiooniga

state: started jätab juba töötava üksuse puutumata, nii et ümber kirjutatud wg0.conf ei rakendu kunagi. Lisage muudatuse handler ja võrrelge seejärel töötavat seadet failiga.

Playbook lõpeb roheliselt, WireGuardi üksus on aktiivne, handshake töötab ja uus peer ei jõua ikkagi kuhugi. Playbooki õnnestumist näha, kui server töötab eilse konfiguratsiooniga, on eriti tüütu, sest väljundis pole midagi valesti. Ansible tegi täpselt seda, mida paluti: tagas, et üksus on käivitatud, ja üksus oli juba käivitatud. Ümber kirjutatud konfiguratsioonifaili rakendamine on teine ülesanne ja juhtub ainult siis, kui miski ütleb teenusele, et see tuleks uuesti lugeda.

Vaadake, mida teine käivitus tegelikult teatab

Käivitage playbook kaks korda muudetud konfiguratsiooniga ja võrrelge kokkuvõtet. Teine käivitus peaks näitama üksuse ülesannet olekuna ok, mitte changed, sest juba töötav teenus jäetakse disaini järgi rahule. See on korrektselt töötav idempotentsus ja ühtlasi põhjus, miks uus fail kunagi kerneli ei jõua.

Lisage diff-väljundiga kontrollkäivitus, et näha, millised ülesanded üldse midagi puudutaksid.

ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.conf

Kolm ajatemplit räägivad loo enne, kui loete ühtki logirida. Kui konfiguratsioonifail on uuem kui hetk, mil üksus aktiivseks sai, on töötav liides ehitatud vanemast failist ja kõik järgnevad sümptomid tulenevad sellest.

See pole Ansible'i viga. Sama käitumine esineb iga konfiguratsioonihalduse tööriista puhul, mis eristab «veendu, et see töötab» ja «veendu, et see töötab just nii». Erinevus tundub pedantne, kuni see maksab teile ühe pärastlõuna.

Käivitatud on olek, mitte uuestilaadimine

state: started väidab üksuse kohta tingimust. See ei luba, et teenus loeb oma sisendid uuesti, ja ei saa teada, et fail, mida ta kunagi ei avanud, on muutunud. wg-quick-i juurutuses hõlmavad sisendid liidese konfiguratsiooni, aadresse, marsruute, DNS-kirjeid ja kõiki post-up-konksusid.

Seetõttu võib uuendatud fail sisaldada uut peeri, teist aadressi või muudetud marsruutimisdirektiivi, samal ajal kui töötav liides teenindab endiselt vana komplekti. Handshake õnnestub endiselt, sest laaditud võtmed ja lõpp-punktid kehtivad veel. Just see teebki rikke raskesti märgatavaks ja selgitab, miks inimesed ajavad tund aega DNS-i taga, enne kui ajatemplit kontrollivad.

Kahte teist mooduli valikut peetakse sageli lahenduseks. daemon_reload paneb systemdi üksusefaile uuesti lugema, mis on WireGuardi konfiguratsioonifaili jaoks ebaoluline. state: reloaded palub üksusel käivitada oma uuestilaadimistoimingu, ja kas see teeb seda, mida vajate, sõltub täielikult üksusest. Kumbki ei asenda teadmist, milliseid sisendeid töötav protsess tegelikult luges.

Paigaldage fail ja teavitage seejärel handlerit

Muster, mis hoiab idempotentsust ja rakendab siiski muudatusi, on tavaline: faili kirjutav ülesanne teavitab handlerit ja handler töötab ainult siis, kui fail tegelikult muutus. Teine käivitus ilma muudatusteta ei tee midagi, ja seda te ju tahate.

- name: write the interface configuration
  ansible.builtin.template:
    src: wg0.conf.j2
    dest: /etc/wireguard/wg0.conf
    owner: root
    mode: "0600"
  notify: apply wg0

- name: ensure the interface unit is enabled
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    enabled: true
    state: started

- name: apply wg0
  listen: apply wg0
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    state: restarted

Handlerid töötavad play lõpus, pärast neid teavitanud ülesandeid, nii et hilisem ülesanne samas plays võib näha veel vana liidest. Kui järjekord on oluline, tühjendage handlerid selgesõnaliselt käsuga meta: flush_handlers enne ülesannet, mis sõltub uuest konfiguratsioonist.

Kasutage restart, mitte reload, kui te pole üksuse uuestilaadimistoimingut kontrollinud. Upstream wg-quick üksus toetab seda ja sünkroonib WireGuardi konfiguratsiooni, kuid ei käivita uuesti aadresside, marsruutide, DNS-i ega konksude seadistust. Seetõttu tundub reload pärast marsruudidirektiivi lisamist õnnestuvat ega muuda midagi.

Võrrelge töötavat seadet failiga

Kontroll, mis selle veaklassi sulgeb, on võrdlus kerneli hoitava ja failis kirjas oleva vahel. Kaks käsku annavad võrreldava väljundi ja erinevus on hälve.

sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)

wg showconf trükib töötava seadme, sealhulgas privaatvõtme, seega käsitlege seda väljundit saladusena ega kleepige seda piletisse. wg-quick strip trükib faili ilma wg-quickile omaste võtmeteta, ja just seetõttu on need kaks üldse võrreldavad.

Erinevus peeride loendis tähendab, et faili ei rakendatud kunagi. Erinevus ainult võtmetes või lõpp-punktides, mille muutumist te ootasite, tähendab, et miski rakendas selle osaliselt. Erinevuse puudumine tähendab, et konfiguratsioon on ajakohane ja viga on mujal, mis on iseenesest kasulik tulemus.

Makske restardi hind teadlikult

Liidese restart kukutab tunnelid, ja kui see tunnel kannab teie haldussessiooni, lõpetab restart sessiooni, mis seda palus. Pange handler muudatuseakna taha või käivitage playbook haldustee kaudu, mis ei sõltu liidese restartimisest.

Hind on põhjus, miks inimesed reloadi järele haaravad. See on mõistlik instinkt ja muutub õigeks, kui teate, milliseid muudatusi reload tegelikult rakendab. Upstream wg-quick üksusel piisab see peeri- ja võtmemuudatuste jaoks; adresseerimise, marsruutimise ja konksude jaoks mitte. Selle üks kord selgeks tegemine on odavam kui selle avastamine muudatuseakna ajal.

Mooduli systemd_service dokumentatsioon selgitab erinevust started, restarted ja reloaded vahel ning tasub üks kord läbi lugeda, selle asemel et seda rohelisest kokkuvõttest oletada. Kõik selles ülevaates tuleneb sellest ühest erinevusest.

Seotud artiklid