ಮರುಪ್ರಾರಂಭದ ನಂತರ WireGuard ಪೀರ್ ಕಣ್ಮರೆ: ನಿಜವಾದ ಸಂರಚನೆಯನ್ನು ಹುಡುಕಿ

wg set ನಿಂದ ಸೇರಿಸಿದ ಪೀರ್ ಮಧ್ಯಾಹ್ನವಿಡೀ ping ಗಳಿಗೆ ಉತ್ತರಿಸಿ, ರೀಬೂಟ್ ನಂತರ ಮಾಯವಾಗುತ್ತದೆ. ಏನೂ ಹಾಳಾಗಿಲ್ಲ: ಕರ್ನೆಲ್ ಆ ಪೀರ್ ಅನ್ನು ಜೀವಂತ ಇಂಟರ್ಫೇಸ್ ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಎಲ್ಲೂ ಸಂಗ್ರಹಿಸಿರಲಿಲ್ಲ, ಮತ್ತು ಬೂಟ್‌ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಮತ್ತೆ ರಚಿಸುವ ಯಾವುದೇ ವಸ್ತು ಅದನ್ನು ನೀವು ಮುಟ್ಟದ ಫೈಲ್‌ನಿಂದ ನಿರ್ಮಿಸಿದೆ. ಸರಿಪಡಿಸುವಿಕೆ ಇನ್ನೊಂದು wg set ಅಲ್ಲ. ಯಾವ ಘಟಕ ಇಂಟರ್ಫೇಸ್‌ನ ಮಾಲೀಕ ಎಂದು ಕಂಡುಹಿಡಿಯುವುದು, ಆ ಘಟಕದ ಸ್ಥಿತಿಯನ್ನು ಸಂಪಾದಿಸುವುದು, ನಂತರ ಪೀರ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದ ಅದೇ ಜೀವನಚಕ್ರದ ಘಟನೆಯಿಂದ ಅದು ಪಾರಾಗುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದು — ಇದೇ ನಿಜವಾದ ದುರಸ್ತಿ.

ಒಮ್ಮೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅದನ್ನು ಪುನರಾವರ್ತಿಸಿ

ಮರುಪ್ರಾರಂಭದ ಸಮಸ್ಯೆ ನಿಮ್ಮ ಕಣ್ಣ ಮುಂದೆ ನಡೆಯುವುದನ್ನು ನೋಡುವವರೆಗೆ ಅದನ್ನು ಸರಿಪಡಿಸಬೇಡಿ. ಕನ್ಸೋಲ್ ಅಥವಾ ಔಟ್-ಆಫ್-ಬ್ಯಾಂಡ್ ಪ್ರವೇಶ ಇದ್ದರೆ ಪೀರ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಬರೆದಿಡಿ, ಇಂಟರ್ಫೇಸ್‌ನ ಮಾಲೀಕರಾದ ಸೇವೆಯ ಮೂಲಕ ಮರುಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಹೋಲಿಸಿ. ಪೀರ್ ಇನ್ನೂ ಇದ್ದರೆ, ನಿಮ್ಮ ಬದಲಾವಣೆ ಈಗಾಗಲೇ ಶಾಶ್ವತ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಿದೆ ಮತ್ತು ನೀವು ತಪ್ಪು ಘಟನೆಯನ್ನು ಡೀಬಗ್ ಮಾಡುತ್ತಿದ್ದೀರಿ.

ಇದನ್ನು ಮಾಡುತ್ತಿರುವಾಗ ಮೂರು ಸಂಗತಿಗಳನ್ನು ಬರೆಯಿರಿ: ಇಂಟರ್ಫೇಸ್‌ನ ಹೆಸರು, ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಯುನಿಟ್ ಅಥವಾ ಪ್ರೊಫೈಲ್, ಮತ್ತು ಉಳಿದುಕೊಂಡ ಪೀರ್‌ನ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಕೌಂಟರ್ ಮರುಹೊಂದಿಸಲಾಗಿದೆಯೇ. ಮರುಹೊಂದಿಸಿದ ಕೌಂಟರ್ ಎಂದರೆ ಇಂಟರ್ಫೇಸ್ ನಾಶವಾಗಿ ಮತ್ತೆ ನಿರ್ಮಾಣವಾಗಿದೆ; ಬದಲಾಗದ ಕೌಂಟರ್ ಮತ್ತು ಕಾಣೆಯಾದ ಪೀರ್ ಎಂದರೆ ಯಾರೋ ನಿಮ್ಮ ಕಾಲ ಕೆಳಗೆ ಸಂರಚನೆಯನ್ನು ಸಂಪಾದಿಸಿದ್ದಾರೆ.

ಇಂಟರ್ಫೇಸ್‌ನ ಮಾಲೀಕರು ಯಾರು?

WireGuard ಗೆ ಸ್ವಂತವಾಗಿ ಯಾವುದೇ ಡೀಮನ್ ಇಲ್ಲ, ಸಂರಚನಾ ಫೈಲ್ ಇಲ್ಲ. ಅದರ ಮೇಲಿನ ಯಾವುದೋ ಒಂದು ಬೂಟ್‌ನಲ್ಲಿ wg ಅನ್ನು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ಅದೇ ಸತ್ಯದ ಮೂಲ. ಸಾಮಾನ್ಯ ಅಭ್ಯರ್ಥಿಗಳೆಂದರೆ [email protected], NetworkManager ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್, ವಿತರಣಾ-ನಿರ್ದಿಷ್ಟ ಜಾಲ ಘಟಕ, ಅಥವಾ ತನ್ನದೇ ಡೇಟಾಬೇಸ್ ಬರೆಯುವ ನಿರ್ವಹಣಾ ಪ್ಯಾನೆಲ್.

ನಿಮ್ಮ ವಿತರಣೆಯ ದಾಖಲೆಗಳನ್ನು ಅಲ್ಲ, ಸಿಸ್ಟಮ್ ಅನ್ನೇ ಕೇಳಿ. systemctl status wg-quick@wg0 ಮತ್ತು nmcli connection show ಸಾಮಾನ್ಯವಾಗಿ ತಲಾ ಒಂದು ಆಜ್ಞೆಯಲ್ಲಿ ಇದನ್ನು ಇತ್ಯರ್ಥ ಮಾಡುತ್ತವೆ. ಎರಡೂ ಇಂಟರ್ಫೇಸ್ ಮೇಲೆ ಹಕ್ಕು ಸಾಧಿಸಿದರೆ, ಏನನ್ನೂ ಸಂಪಾದಿಸುವ ಮೊದಲೇ ನೀವು ದೋಷವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ: ಇಬ್ಬರು ಮಾಲೀಕರು ಪ್ರತಿ ಪ್ರಾರಂಭದಲ್ಲೂ ಅದೇ ಸಾಧನವನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತಾರೆ, ಮತ್ತು ಕೊನೆಯದಾಗಿ ಓಡುವವನೇ ಗೆಲ್ಲುತ್ತಾನೆ.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

ರನ್‌ಟೈಮ್ ಸ್ಥಿತಿ ಮತ್ತು ಸ್ಟಾರ್ಟಪ್ ಸ್ಥಿತಿ ಒಂದೇ ಫೈಲ್ ಅಲ್ಲ

wg set ಜೀವಂತ ಸಾಧನವನ್ನು netlink ಮೂಲಕ ನಿರ್ವಹಿಸುತ್ತದೆ. ಅದು /etc/wireguard/wg0.conf, NetworkManager ಪ್ರೊಫೈಲ್ ಅಥವಾ ಪ್ಯಾನೆಲ್‌ನ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬರೆಯುವುದಿಲ್ಲ. ನಂತರದ ಯಶಸ್ವಿ wg show ಕರ್ನೆಲ್ ಪೀರ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಯಾವುದೋ ಅದನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ ಎಂದಲ್ಲ.

ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಎರಡನೇ ಬಲೆ ಇದೆ. ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕೆಳಗಿಳಿಸುವಾಗ wg-quick ನ SaveConfig ಆಯ್ಕೆ ಪ್ರಸ್ತುತ ಇಂಟರ್ಫೇಸ್ ಸ್ಥಿತಿಯನ್ನು ಸಂರಚನಾ ಫೈಲ್‌ಗೆ ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. ಅದು ಆನ್ ಆಗಿದ್ದರೆ, ಇಂಟರ್ಫೇಸ್ ಮೇಲಿರುವಾಗ ಫೈಲ್‌ನಲ್ಲಿ ಮಾಡಿದ ಸಂಪಾದನೆಯು ನಂತರದ ಆಫ್ ಆಗುವಿಕೆಯಿಂದ ಮೇಲೆ ಬರೆಯಬಹುದು, ಮತ್ತು ಆ ಸಾಲು ಅಲ್ಲಿತ್ತು ಎಂದು ನೀವು ಪ್ರಮಾಣ ಮಾಡುತ್ತೀರಿ. ಪೀರ್ ಪದೇ ಪದೇ ಮರಳುತ್ತಿದ್ದರೆ, ಫೈಲ್ ಅನ್ನು ನಿಲ್ಲಿಸಿದ ನಂತರ ಓದಿ, ಮೊದಲು ಅಲ್ಲ.

NetworkManager ಮತ್ತೆ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ: ಪ್ರೊಫೈಲ್ ಅದರದ್ದು ಮತ್ತು ಸಕ್ರಿಯಗೊಳಿಸುವಾಗ ಅದನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಕ್ರಿಯ NetworkManager ಸಂಪರ್ಕದ ಪಕ್ಕದಲ್ಲಿ ಕೈಯಿಂದ ಸಂಪಾದಿಸಿದ .conf ಕೇವಲ ಅಲಂಕಾರ. ಇಂಟರ್ಫೇಸ್‌ಗೆ ಒಬ್ಬ ಮಾಲೀಕರನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಮತ್ತು ಇನ್ನೊಬ್ಬ ಮ್ಯಾನೇಜರ್ ಅದನ್ನು ಬಿಟ್ಟುಬಿಡಲಿ.

ಸಂಪಾದನೆ ಎರಡೂ ಕಡೆ ತಲುಪುವಂತೆ ಮಾಡಿ

ಮೊದಲು ಶಾಶ್ವತ ಸ್ಥಿತಿಯನ್ನು ಸಂಪಾದಿಸಿ, ನಂತರ ಮಾಲೀಕರು ಅದನ್ನು ಅನ್ವಯಿಸಲಿ, ಬಳಿಕ ಜೀವಂತ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಈ ಕ್ರಮ ಎಂದರೆ ಯಾವುದೇ ಹಂತದಲ್ಲಿ ವೈಫಲ್ಯ ಮೂರಲ್ಲ, ಒಂದು ವಸ್ತುವಿನತ್ತ ತೋರಿಸುತ್ತದೆ.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf ಜೀವಂತ ಸಂರಚನೆಯನ್ನು ಫೈಲ್ ಬಳಸುವ ಅದೇ ವಾಕ್ಯರಚನೆಯಲ್ಲಿ ಮುದ್ರಿಸುತ್ತದೆ, ಇದು ಎರಡನ್ನೂ ನೇರವಾಗಿ ಹೋಲಿಸಲು ಅನುವು ಮಾಡುತ್ತದೆ. ಆ ಔಟ್‌ಪುಟ್ ಅನ್ನು ರಹಸ್ಯವೆಂದು ಪರಿಗಣಿಸಿ: ಅದರಲ್ಲಿ ಖಾಸಗಿ ಕೀಗಳಿವೆ, ಆದ್ದರಿಂದ ಟಿಕೆಟ್ ಅಥವಾ ಚಾಟ್ ಚಾನೆಲ್‌ನಲ್ಲಿ ಅಂಟಿಸಬೇಡಿ. ಪೀರ್‌ಗಳ ಸಾರ್ವಜನಿಕ ಕೀಗಳು ಮತ್ತು ಅನುಮತಿಸಿದ IP ಗಳನ್ನು ಹೋಲಿಸಿ, ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ತೆಗೆದ ಪೀರ್ ಮರಳಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಅದು ಜೀವನಚಕ್ರದ ಘಟನೆಯಿಂದ ಪಾರಾಗುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ

ಮಾಲೀಕರ ಮೂಲಕ ಎರಡನೇ ಬಾರಿ ಮರುಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಮೂರು ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳನ್ನು ದೃಢೀಕರಿಸಿ: ಪೀರ್ wg show ನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ, ಸಂಚಾರದ ನಂತರ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಕೌಂಟರ್ ಹೆಚ್ಚಾಗುತ್ತದೆ, ಮತ್ತು ಸುರಂಗದ ಮೇಲೆ ಅವಲಂಬಿತವಾದ ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿಯೂ ಉತ್ತರಿಸುತ್ತದೆ. ಹಳೆಯ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನೊಂದಿಗೆ ಪಟ್ಟಿಮಾಡಿದ ಪೀರ್ ಎಂಬುದು ರೂಟಿಂಗ್ ಅಥವಾ ಕೀ ಸಮಸ್ಯೆ, ಶಾಶ್ವತತೆಯ ಸಮಸ್ಯೆ ಅಲ್ಲ, ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸವು ನಿಷ್ಪ್ರಯೋಜಕ ಸಂರಚನಾ ಸಂಪಾದನೆಯನ್ನು ಉಳಿಸುತ್ತದೆ.

ಕೊನೆಯದಾಗಿ, ಮರುಪ್ರಾರಂಭ ಏನನ್ನು ಮರುಸ್ಥಾಪಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ. ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ತೆಗೆದ ಪೀರ್ ಅನ್ನು ಪುನರ್ಜೀವಗೊಳಿಸುವ ಮರುಪ್ರಾರಂಭ ಅದೇ ದೋಷದ ವಿರುದ್ಧ ಚಿಹ್ನೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಸಂರಚನೆಯ ಹಳೆಯ ಪ್ರತಿ ಇನ್ನೂ ಎಲ್ಲಿಂದಲೋ ಲೋಡ್ ಆಗುತ್ತಿದೆ ಎಂದರ್ಥ. ಮಾಲೀಕ, ಫೈಲ್ ಮಾರ್ಗ, ಪೀರ್‌ನ ಸಾರ್ವಜನಿಕ ಕೀ ಮತ್ತು ಪರಿಶೀಲನಾ ಆಜ್ಞೆಗಳನ್ನು ಸಂರಚನೆಯ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಉತ್ಪಾದನಾ ಹೋಸ್ಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಇದನ್ನು ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳದಂತೆ.