Sabi ng Ansible nasimulan na, pero gumagamit pa rin ang WireGuard ng lumang config

Nagtatapos nang berde ang pagtakbo ng playbook, aktibo ang unit ng WireGuard, gumagana ang handshake, at wala pa ring naaabot ang bagong peer. Ang makitang nag-uulat ng tagumpay ang playbook habang tumatakbo ang server sa config ng kahapon ay espesyal na nakakainis, dahil walang mali sa output. Ginawa ng Ansible ang eksaktong hiniling: siniguro nitong nasimulan ang unit, at nasimulan na ito. Ang paglalapat ng muling isinulat na config file ay ibang gawain, at nangyayari lamang kapag may nagsabi sa serbisyo na basahin itong muli.

Tingnan kung ano talaga ang iniuulat ng ikalawang pagtakbo

Patakbuhin ang playbook nang dalawang beses kasama ang binagong config at ihambing ang buod. Dapat ipakita ng ikalawang pagtakbo ang gawain ng unit bilang ok, hindi changed, dahil ang serbisyong tumatakbo na ay sadyang hinahayaang tahimik. Iyon ang idempotence na gumagana nang tama, at iyon din ang dahilan kung bakit hindi kailanman naaabot ng bagong file ang kernel.

Magdagdag ng check run na may diff output para makita kung aling mga gawain ang may tatamaan.

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

Sinasabi ng tatlong timestamp ang kuwento bago ka pa magbasa ng isang linya ng log. Kung ang config file ay mas bago kaysa sa sandaling naging aktibo ang unit, ang interface na tumatakbo ay ginawa mula sa mas lumang file, at ang lahat ng sumusunod na sintomas ay nagmumula roon.

Hindi ito depekto ng Ansible. Lumilitaw ang parehong ugali sa anumang tool sa pamamahala ng config na naghihiwalay ng «siguraduhing tumatakbo» sa «siguraduhing ito ang tinatakbo». Ang pagkakaiba ay mukhang sobrang pino hanggang sa makabawas ito ng isang hapon.

Ang nasimulan ay estado, hindi reload

state: started ay nagsasaad ng kondisyon tungkol sa unit. Hindi nito ipinapangako na muling babasahin ng serbisyo ang mga input nito, at hindi nito malalaman na nagbago ang file na hindi nito kailanman binuksan. Sa deployment na wg-quick, kasama sa mga input ang config ng interface, mga address, ruta, entry ng DNS at anumang post-up hook.

Kaya ang na-update na file ay maaaring may bagong peer, ibang address o binagong routing directive habang patuloy na inihahatid ng live interface ang lumang set. Nagtatagumpay pa rin ang handshake dahil valid pa ang mga na-load na key at endpoint. Iyon mismo ang nagpapahirap makita ang pagkabigo, at dahilan kung bakit hinahabol ng mga tao ang DNS nang isang oras bago suriin ang timestamp.

Dalawang iba pang opsyon ng module ang madalas napagkakamalang solusyon. daemon_reload ay nagpapabasang muli sa systemd ng mga unit file, na walang kaugnayan sa config file ng WireGuard. state: reloaded ay humihiling sa unit na isagawa ang reload action nito, at kung ginagawa nito ang kailangan mo ay buong nakasalalay sa unit. Wala sa dalawa ang kapalit ng pag-alam kung aling input ang aktwal na binasa ng tumatakbong proseso.

I-install ang file, pagkatapos abisuhan ang handler

Ang pattern na nagpapanatili ng idempotence at naglalapat pa rin ng mga pagbabago ay ang karaniwan: ang gawaing nagsusulat ng file ay nag-aabiso sa handler, at tumatakbo lamang ang handler kapag tunay na nagbago ang file. Ang ikalawang pagtakbo na walang pag-edit ay walang ginagawa, at iyon ang gusto mo.

- 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

Tumatakbo ang mga handler sa dulo ng play, pagkatapos ng mga gawaing nag-abiso sa kanila, kaya ang gawaing mas huli sa parehong play ay maaaring makita pa ang lumang interface. Kung mahalaga ang pagkakasunod-sunod, tahasang i-empty ang mga handler gamit ang meta: flush_handlers bago ang gawaing umaasa sa bagong config.

Gumamit ng restart kaysa reload maliban kung na-verify mo ang reload action ng unit. Sinusuportahan ito ng upstream wg-quick unit at ini-sync ang config ng WireGuard, ngunit hindi nito muling pinapatakbo ang setup ng address, ruta, DNS o hook. Kaya ang reload pagkatapos magdagdag ng ruta directive ay mukhang matagumpay at walang binabago.

Ihambing ang live na device sa file

Ang check na nagsasara sa ganitong uri ng bug ay paghahambing ng hawak ng kernel at sinasabi ng file. Dalawang command ang gumagawa ng maihahambing na output, at ang pagkakaiba ay ang paglihis.

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

wg showconf ay nagpi-print ng live na device, kasama ang pribadong key, kaya ituring na lihim ang output na iyon at huwag idikit sa ticket. wg-quick strip ay nagpi-print ng file nang walang mga key na partikular sa wg-quick, at kaya maihahambing ang dalawa.

Ang pagkakaiba sa listahan ng peer ay nangangahulugang hindi kailanman nailapat ang file. Ang pagkakaiba lamang sa mga key o endpoint na inaasahan mong magbabago ay nangangahulugang may naglapat nito nang bahagi. Walang pagkakaiba ay nangangahulugang updated ang config at nasa ibang lugar ang problema, na kapaki-pakinabang na resulta na sa sarili nito.

Bayaran ang halaga ng restart nang sadya

Pinapatid ng restart ng interface ang tunnel, at kung dinadala ng tunnel na iyon ang admin session mo, tinatapos ng restart ang session na humiling nito. Ilagay ang handler sa likod ng change window, o patakbuhin ang playbook mula sa management path na hindi umaasa sa restart ng interface.

Ang halaga ang dahilan kung bakit lumalapit ang mga tao sa reload. Iyon ay makatwirang instinct, at nagiging tama kapag alam mo kung aling pagbabago ang aktwal na inilalapat ng reload. Para sa pagbabago ng peer at key sa upstream wg-quick unit ay sapat ito; para sa addressing, routing at hook ay hindi. Ang linawin ito nang isang beses ay mas mura kaysa matuklasan ito habang may change window.

Ang dokumentasyon ng module na systemd_service ay nagpapaliwanag ng pagkakaiba ng started, restarted at reloaded, at sulit itong basahin nang isang beses kaysa hulaan mula sa berdeng buod. Ang lahat sa gabay na ito ay nagmumula sa nag-iisang pagkakaibang iyon.