Ansible эхэлсэн гэж хэлдэг ч WireGuard хуучин тохиргоогоор ажиллаж байна

state: started аль хэдийн ажиллаж байгаа unit-д хүрэхгүй тул дахин бичсэн wg0.conf хэзээ ч хэрэгжихгүй. Өөрчлөлтийн handler нэмээд дараа нь ажиллаж байгаа төхөөрөмжийг файлтай харьцуулна уу.

Playbook ажиллагаа ногооноор дуусна, WireGuard unit идэвхтэй, handshake ажиллаж байна, гэхдээ шинэ peer юунд ч хүрэхгүй. Сервер өчигдрийн тохиргоогоор ажиллаж байхад playbook амжилт мэдээлж байгааг харах нь онцгой бухимдал төрүүлдэг, учир нь гаралтад буруу зүйл байхгүй. Ansible яг хүссэнийг хийсэн: unit эхэлсэн эсэхийг баталгаажуулсан бөгөөд unit аль хэдийн эхэлсэн байв. Дахин бичсэн тохиргооны файлыг хэрэгжүүлэх нь өөр ажил бөгөөд ямар нэг зүйл үйлчилгээг дахин уншихыг хэлэхэд л тохиолддог.

Хоёр дахь ажиллагаа үнэндээ юу мэдээлж байгааг хараарай

Өөрчилсөн тохиргоотой playbook-ыг хоёр удаа ажиллуулж, дүгнэлтийг харьцуулна уу. Хоёр дахь ажиллагаа unit-ийн даалгаврыг changed биш ok гэж харуулах ёстой, учир нь аль хэдийн ажиллаж байгаа үйлчилгээг зохион бүтээлээр тайван үлдээдэг. Энэ бол зөв ажиллаж байгаа idempotence бөгөөд шинэ файл хэзээ ч kernel-д хүрэхгүйн шалтгаан ч мөн адил.

diff гаралттай шалгалтын ажиллагаа нэмж, аль даалгавар юунд ч хүрэхийг хараарай.

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

Гурван цагийн тэмдэглэгээ нэг лог мөр уншихаас өмнө түүхийг өгүүлнэ. Хэрэв тохиргооны файл unit идэвхтэй болсон мөчөөс илүү шинэ бол ажиллаж байгаа интерфейс хуучин файлаас бүтсэн бөгөөд дараагийн бүх шинж тэмдэг тэндээс гарна.

Энэ нь Ansible-ийн алдаа биш. «Ажиллаж байгаа эсэхийг батал» ба «яг үүнийг ажиллуулж байгаа эсэхийг батал» гэж ялгадаг аливаа тохиргооны удирдлагын хэрэгсэлд ижил зан төлөв илэрдэг. Энэ ялгаа нь хагас өдөр алдахаас өмнө хэт нарийн мэт санагддаг.

Эхэлсэн нь төлөв, дахин ачаалалт биш

state: started unit-ийн талаар нөхцөл батална. Энэ нь үйлчилгээ оруулгуудаа дахин уншина гэж амлахгүй бөгөөд хэзээ ч нээж үзээгүй файл өөрчлөгдсөнийг мэдэж чадахгүй. wg-quick байршуулалтад оруулгуудад интерфейсийн тохиргоо, хаягууд, маршрутууд, DNS бичлэгүүд болон аливаа post-up hook багтана.

Тиймээс шинэчлэгдсэн файлд шинэ peer, өөр хаяг эсвэл өөрчлөгдсөн маршрутжуулалтын заавар байж болох бөгөөд ажиллаж байгаа интерфейс хуучин багцыг үйлчилсээр байна. Handshake одоо ч амжилттай байгаа нь ачаалсан түлхүүр, төгсгөлийн цэгүүд хүчинтэй хэвээр байгаатай холбоотой. Яг энэ нь алдааг илрүүлэхэд хэцүү болгож, хүмүүс цагийн тэмдэглэгээг шалгахаас өмнө нэг цаг DNS-ийн араас гүйдэг.

Модулийн өөр хоёр сонголтыг шийдэл гэж андуурдаг. daemon_reload systemd-д unit файлуудыг дахин уншуулдаг боловч энэ нь WireGuard тохиргооны файлд хамаагүй. state: reloaded unit-ээс дахин ачаалах үйлдлээ гүйцэтгэхийг хүсдэг бөгөөд энэ нь таны хэрэгцээг хангах эсэх нь бүхэлдээ unit-ээс хамаарна. Аль нь ч ажиллаж байгаа процесс ямар оруулгуудыг үнэхээр уншсаныг мэдэх-ийг орлохгүй.

Файлыг суулгаад дараа нь handler-д мэдэгдэнэ

Idempotence-ийг хадгалж, өөрчлөлтийг хэрэгжүүлдэг загвар нь энгийн: файлыг бичдэг даалгавар handler-д мэдэгдэж, handler зөвхөн файл үнэхээр өөрчлөгдсөн үед ажиллана. Засваргүй хоёр дахь ажиллагаа юу ч хийдэггүй бөгөөд танд хэрэгтэй зүйл ч мөн адил.

- 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

Handler-ууд play-ийн төгсгөлд, тэдэнд мэдэгдсэн даалгавруудын дараа ажилладаг тул мөн play-ийн хожуу даалгавар хуучин интерфейсийг харж болно. Дараалал чухал бол шинэ тохиргооноос хамаарах даалгаврын өмнө handler-уудыг meta: flush_handlers-ээр тодорхой хоослоорой.

Unit-ийн дахин ачаалах үйлдлийг шалгаагүй бол reload-ийн оронд restart хэрэглээрэй. Upstream wg-quick unit үүнийг дэмждэг бөгөөд WireGuard тохиргоог синхрончилдог ч хаяг, маршрут, DNS, hook-ийн тохируулгыг дахин гүйцэтгэдэггүй. Тиймээс маршрутын заавар нэмсний дараах reload амжилттай мэт харагдаж, юу ч өөрчлөхгүй.

Ажиллаж байгаа төхөөрөмжийг файлтай харьцуул

Энэ төрлийн алдааг хаадаг шалгалт нь kernel-ийн хадгалж байгаа болон файлд бичсэн зүйлийн харьцуулалт юм. Хоёр команд харьцуулах боломжтой гаралт өгдөг бөгөөд ялгаа нь хазайлт юм.

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

wg showconf хувийн түлхүүрийг оруулан ажиллаж байгаа төхөөрөмжийг хэвлэдэг тул энэ гаралтыг нууц гэж үзэж, тасалбарт нааж болохгүй. wg-quick strip wg-quick-д хамаарах түлхүүргүйгээр файлыг хэвлэдэг тул хоёулаа харьцуулагдана.

Peer жагсаалтын ялгаа нь файл хэзээ ч хэрэгжээгүйг илтгэнэ. Зөвхөн өөрчлөгдөнө гэж күтсэн түлхүүр, төгсгөлийн цэгүүдийн ялгаа нь ямар нэг зүйл үүнийг хэсэгчлэн хэрэгжүүлснийг илтгэнэ. Ялгаа огт байхгүй бол тохиргоо одоогийн бөгөөд алдаа өөр газар байна, энэ нь өөрөө ашигтай үр дүн юм.

Дахин эхлүүлэх зардлыг санаатайгаар төл

Интерфейсийг дахин эхлүүлэхэд туннель тасардаг бөгөөд хэрэв тэр туннель таны админ сессийг зөөж байгаа бол дахин эхлүүлэлт түүнийг хүссэн сессийг дуусгана. Handler-ыг өөрчлөлтийн цонхны ард байрлуул эсвэл playbook-ыг интерфейсийн дахин эхлэлтээс хамааралгүй удирдлагын замаас ажиллуул.

Энэ зардал л хүмүүсийг reload руу түлхдэг. Энэ нь боломжийн зөн совин бөгөөд reload ямар өөрчлөлтийг үнэхээр хэрэгжүүлдэг гэдгийг мэдвэл зөв болно. Upstream wg-quick unit дээр peer, түлхүүрийн өөрчлөлтөд хангалттай; хаяг, маршрутжуулалт, hook-д хангалтгүй. Үүнийг нэг удаа тодруулах нь өөрчлөлтийн цонхны үеэр олж мэдэхээс хямд.

systemd_service модулийн баримт бичиг started, restarted, reloaded-ийн ялгааг тайлбарладаг бөгөөд ногоон дүгнэлтээс таамаглахын оронд нэг удаа унших нь зүйтэй. Энэ гарын авлагын бүх зүйл тэр нэг ялгаанаас үүдэлтэй.

Холбоотой нийтлэлүүд