Ansible hlási spustené, no WireGuard stále beží so starou konfiguráciou

state: started nechá bežiacu jednotku na pokoji, takže prepísaný wg0.conf sa nikdy nepoužije. Pridajte handler zmeny a potom porovnajte živé zariadenie so súborom.

Beh playbooku sa skončí zeleno, jednotka WireGuard je aktívna, handshake funguje a nový peer sa napriek tomu nikam nedostane. Sledovať, ako playbook hlási úspech, kým server beží s včerajšou konfiguráciou, je obzvlášť otravné, pretože vo výstupe nie je nič nesprávne. Ansible urobil presne to, o čo bol požiadaný: zabezpečil, že jednotka je spustená, a jednotka už spustená bola. Použitie prepísaného konfiguračného súboru je iná úloha a nastane len vtedy, keď niečo povie službe, aby ho znova načítala.

Pozrite sa, čo druhý beh skutočne hlási

Spustite playbook dvakrát so zmenenou konfiguráciou a porovnajte zhrnutie. Druhý beh by mal úlohu jednotky zobraziť ako ok, nie changed, pretože bežiaca služba sa zámerne necháva na pokoji. To je idempotencia fungujúca správne a zároveň dôvod, prečo sa nový súbor nikdy nedostane do jadra.

Pridajte kontrolný beh s výstupom diff, aby ste videli, ktoré úlohy by sa vôbec niečoho dotkli.

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

Tri časové značky povedia celý príbeh skôr, než prečítate jediný riadok logu. Ak je konfiguračný súbor novší než okamih, keď sa jednotka stala aktívnou, bežiace rozhranie bolo zostavené zo staršieho súboru a všetky ďalšie príznaky z toho vyplývajú.

Nie je to chyba Ansible. Rovnaké správanie sa objavuje pri každom nástroji na správu konfigurácie, ktorý oddeľuje „uisti sa, že to beží“ od „uisti sa, že to beží presne toto“. Rozdiel vyzerá pedantne, kým vás nestojí popoludnie.

Spustené je stav, nie opätovné načítanie

state: started tvrdí podmienku o jednotke. Nesľubuje, že služba znova prečíta svoje vstupy, a nemôže vedieť, že súbor, ktorý nikdy neotvorila, sa zmenil. Pri nasadení wg-quick vstupy zahŕňajú konfiguráciu rozhrania, adresy, trasy, záznamy DNS a akékoľvek post-up háčiky.

Preto môže aktualizovaný súbor obsahovať nový peer, inú adresu alebo zmenenú smerovaciu direktívu, kým živé rozhranie naďalej obsluhuje starú množinu. Handshake stále prejde, pretože načítané kľúče a koncové body sú stále platné. Práve to robí zlyhanie ťažko viditeľným a preto ľudia hodinu prenasledujú DNS, kým skontrolujú časovú značku.

Dve ďalšie možnosti modulu sa často považujú za riešenie. daemon_reload prinúti systemd znova načítať jednotkové súbory, čo je pre konfiguráciu WireGuardu irelevantné. state: reloaded žiada jednotku o vykonanie akcie opätovného načítania, a či robí to, čo potrebujete, závisí výlučne od jednotky. Ani jedna nenahrádza vedomosť, ktoré vstupy bežiaci proces skutočne prečítal.

Nainštalujte súbor a potom upovedomte handler

Vzor, ktorý zachováva idempotenciu a napriek tomu aplikuje zmeny, je obvyklý: úloha, ktorá zapisuje súbor, upovedomí handler a handler sa spustí len vtedy, keď sa súbor skutočne zmenil. Druhý beh bez úprav neurobí nič, a to je presne to, čo chcete.

- 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

Handlery sa spúšťajú na konci playu, po úlohách, ktoré ich upovedomili, takže neskoršia úloha v tom istom playi môže ešte vidieť staré rozhranie. Ak záleží na poradí, vyprázdnite handlery explicitne pomocou meta: flush_handlers pred úlohou, ktorá závisí od novej konfigurácie.

Používajte restart namiesto reloadu, ak ste neoverili akciu opätovného načítania jednotky. Upstream jednotka wg-quick ju podporuje a synchronizuje konfiguráciu WireGuardu, ale znova nespúšťa nastavenie adries, trás, DNS ani háčikov. Preto reload po pridaní smerovacej direktívy vyzerá úspešne a nič nezmení.

Porovnajte živé zariadenie so súborom

Kontrola, ktorá uzatvára túto triedu chýb, je porovnanie toho, čo drží jadro, s tým, čo hovorí súbor. Dva príkazy dávajú porovnateľný výstup a rozdiel je odchýlka.

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

wg showconf vypisuje živé zariadenie vrátane súkromného kľúča, takže s tým výstupom zaobchádzajte ako s tajomstvom a nevkladajte ho do tiketu. wg-quick strip vypisuje súbor bez kľúčov špecifických pre wg-quick, a preto sú oba výstupy vôbec porovnateľné.

Rozdiel v zozname peerov znamená, že súbor nebol nikdy použitý. Rozdiel len v kľúčoch alebo koncových bodoch, ktorých zmenu ste očakávali, znamená, že ho niečo použilo čiastočne. Žiadny rozdiel znamená, že konfigurácia je aktuálna a chyba je inde, čo je samo o sebe užitočný výsledok.

Zaplaťte cenu reštartu vedome

Reštart rozhrania preruší tunel, a ak ten tunel nesie vašu administratívnu reláciu, reštart ukončí reláciu, ktorá ho vyžiadala. Umiestnite handler za okno zmien alebo spúšťajte playbook z riadiacej cesty, ktorá nezávisí od reštartu rozhrania.

Cena je dôvod, prečo ľudia siahajú po reloade. Je to rozumný inštinkt a správny sa stane, keď viete, ktoré zmeny reload skutočne aplikuje. Pri zmenách peerov a kľúčov na upstream jednotke wg-quick to stačí; pri adresovaní, smerovaní a háčikoch nie. Raz si to ujasniť je lacnejšie než to objaviť počas okna zmien.

Dokumentácia modulu systemd_service vysvetľuje rozdiel medzi started, restarted a reloaded a stojí za jedno prečítanie namiesto hádania zo zeleného zhrnutia. Všetko v tomto sprievodcovi vyplýva z toho jediného rozdielu.

Súvisiace články