Nebula ಪ್ರಮಾಣಪತ್ರ ಮರುಲೋಡ್ IP ಅನ್ನು ಬದಲಿಸಲಿಲ್ಲ: ಕಾರಣ ಇಲ್ಲಿದೆ
ಮರುಲೋಡ್ ಹೋಸ್ಟ್ ರುಜುವಾತುಗಳನ್ನು ಮತ್ತೆ ಓದುವುದು overlay ವಿಳಾಸವು ಹಾಗೆಯೇ ಉಳಿದಾಗ ಮಾತ್ರ. ವಿಳಾಸ ಬದಲಿಸುವುದು ಎಂದರೆ ಮರುಪ್ರಾರಂಭ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆ, ಮತ್ತೊಮ್ಮೆ ಪ್ರಯತ್ನಿಸುವುದಲ್ಲ.
ನೀವು ಬೇರೆ overlay ವಿಳಾಸದೊಂದಿಗೆ ಹೊಸ ಹೋಸ್ಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೀಡುತ್ತೀರಿ, ಅದನ್ನು ಹಳೆಯ ಫೈಲ್ ಮೇಲೆ ನಕಲಿಸುತ್ತೀರಿ, ಮರುಲೋಡ್ ಕಳುಹಿಸುತ್ತೀರಿ, ಮತ್ತು ಹೋಸ್ಟ್ ಹಿಂದಿನ ವಿಳಾಸದಲ್ಲೇ ಉತ್ತರಿಸುತ್ತಿರುತ್ತದೆ. ಸಹಜ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ ಮರುಲೋಡ್ ವಿಫಲವಾಯಿತು ಅಥವಾ ತಪ್ಪು ಫೈಲ್ ಓದಲಾಯಿತು ಎಂದು ಭಾವಿಸುವುದು. ಸಾಮಾನ್ಯವಾಗಿ ಎರಡೂ ಆಗಿಲ್ಲ: ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯು ಈಗಾಗಲೇ ಇದ್ದ ಗುರುತನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಉಳಿಸಿಕೊಂಡಿತು, ಏಕೆಂದರೆ ಬದಲಿ ಮರುಲೋಡ್ ಅನ್ವಯಿಸಲಾಗದ ಯಾವುದನ್ನೋ ಬದಲಿಸಿತು.
Nebula ನ PKI ಮರುಲೋಡ್ ಬೆಂಬಲವನ್ನು ಅದೇ ಮಿತಿಯೊಂದಿಗೆ ದಾಖಲಿಸಲಾಗಿದೆ, ಮತ್ತು ಅದೇ ದಾಖಲೆ ಇತರ ಬದಲಾವಣೆಗಳಿಗೆ ಮರುಲೋಡ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ತೋರಿಸಿದಾಗ ಅದನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಸುಲಭ.
ಮರುಲೋಡ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಮತ್ತೆ ಓದುತ್ತದೆ
ಹೋಸ್ಟ್ ಪ್ರಮಾಣಪತ್ರವು SSH ಕೀಯಂತಹ ಕೇವಲ ರುಜುವಾತು ಅಲ್ಲ. ಅದು overlay ವಿಳಾಸ, ಹೋಸ್ಟ್ ಹೆಸರು, ಗುಂಪು ಸದಸ್ಯತ್ವಗಳು ಮತ್ತು ಮಾನ್ಯತೆಯ ಅವಧಿಯನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಇವೆಲ್ಲವೂ CA ಯ ಸಹಿಯಿಂದ ಒಟ್ಟಿಗೆ ಬಂಧಿಸಲಾಗಿದೆ. ಡೀಮನ್ ಆ ಸಹಿ ಮಾಡಿದ ವಿಷಯವನ್ನು ತನ್ನನ್ನು ಹೇಗೆ ಪ್ರಸ್ತುತಪಡಿಸಬೇಕು ಮತ್ತು ಯಾವ ನಿಯಮಗಳು ಅನ್ವಯವಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಬಳಸುತ್ತದೆ.
ಮರುಲೋಡ್ ಪ್ರಕ್ರಿಯೆಗೆ ತನ್ನ ಸುರಂಗಗಳನ್ನು ಬಿಟ್ಟುಕೊಡದೆ ನವೀಕೃತ ರುಜುವಾತುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ, ಇದು ನಿಯಮಿತ ರೊಟೇಶನ್‌ಗೆ ಮೌಲ್ಯಯುತ: ಅದೇ ವಿಳಾಸ, ಅದೇ ಹೆಸರು, ಅದೇ ಗುಂಪುಗಳು, ನಂತರದ ಮುಕ್ತಾಯ. ನಿರ್ಬಂಧ ಎಂದರೆ ಗುರುತು ಹಾಗೆಯೇ ಇರಬೇಕು. overlay ವಿಳಾಸ ಬದಲಿಸಿದರೆ ಮರುಲೋಡ್ ಮಾರ್ಗವು ಅದನ್ನು ಅನ್ವಯಿಸಲಾರದು, ಏಕೆಂದರೆ ವಿಳಾಸವು ಚಾಲನೆಯಲ್ಲಿರುವ ನಿದರ್ಶನ ಈಗಾಗಲೇ ಒಪ್ಪಿಕೊಂಡ ವಿಷಯದ ಭಾಗವಾಗಿದೆ.
ಆದ್ದರಿಂದ ನೀವು ಕಂಡ ನಡವಳಿಕೆ ದಾಖಲಿತ ಮಿತಿ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಮೌನ ವೈಫಲ್ಯವಲ್ಲ. ಡಿಸ್ಕಿನಲ್ಲಿರುವ ಫೈಲ್ ಹೊಸದು; ಮೆಮೊರಿಯಲ್ಲಿರುವ ಗುರುತು ಹಳೆಯದು; ಮರುಪ್ರಾರಂಭವಿಲ್ಲದೆ ಆ ವ್ಯತ್ಯಾಸವನ್ನು ಸಮನ್ವಯ ಮಾಡಲು ಪ್ರಕ್ರಿಯೆಗೆ ಯಾವುದೇ ಬೆಂಬಲಿತ ಮಾರ್ಗವಿಲ್ಲ.
ವಿಳಾಸ, ಹೆಸರು ಮತ್ತು ಗುಂಪುಗಳು ಒಂದೇ ಗುರುತು
ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಸಂಪಾದಿಸಬಹುದಾದ ಕ್ಷೇತ್ರಗಳ ಗುಂಪಾಗಿ ಅಲ್ಲ, ಒಂದೇ ದಾಖಲೆಯಾಗಿ ನೋಡುವುದು ಸಹಾಯಕ. ವಿಳಾಸವನ್ನು ಸರಿಸುವುದು ಪ್ರಾಶಸ್ತ್ಯ ಬದಲಿಸುವಂತಿಲ್ಲ, ಏಕೆಂದರೆ ವಿಳಾಸವು ಇತರ ಹೋಸ್ಟ್‌ಗಳ ಪೀರ್ ಸಂರಚನೆಗಳಲ್ಲಿ, ಸೇವಾ ಬೈಂಡಿಂಗ್‌ಗಳಲ್ಲಿ ಮತ್ತು ಗುರುತಿನ ವಿರುದ್ಧ ಬರೆದ ನೀತಿಗಳಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ.
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
ಗುಂಪುಗಳು ತಮ್ಮದೇ ಸಾಲಿಗೆ ಅರ್ಹ, ಏಕೆಂದರೆ ಅವು ಅದೇ ಗೊಂದಲದ ಹೆಚ್ಚು ಶಾಂತ ಆವೃತ್ತಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಂಡು ಗುಂಪು ಬದಲಿಸುವ ಹೋಸ್ಟ್ ಮರುಪ್ರಾರಂಭದ ನಂತರ ಬೇರೆ ಸೇವೆಗಳನ್ನು ತಲುಪಬಹುದು, ಮತ್ತು ಹಳೆಯ ವಿಳಾಸಕ್ಕೆ ಮಾತ್ರ ping ಮಾಡುವ ಪರೀಕ್ಷೆ ಸಂಪೂರ್ಣ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಕೆಳಗೆ ಪ್ರವೇಶ ನಿರ್ಧಾರಗಳು ಬದಲಾಗಿವೆ. ಕೇವಲ ತಲುಪುವಿಕೆಯಲ್ಲ, ನಿಯಮದ ಅಡಿಯಲ್ಲಿರುವ ಒಂದು ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಸುರಂಗವನ್ನು ಖಚಿತಪಡಿಸುವುದು ಮತ್ತು ನೀತಿಯನ್ನು ಖಚಿತಪಡಿಸುವುದರ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಅದೇ.
ಲೋಡ್ ಮಾಡಿದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬದಲಿಗೆ ಹೋಲಿಸಿ
ಡೀಮನ್ ಫೈಲ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿತು ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ಓದಿ. ನೀವು ಲೋಡ್ ಮಾಡಲು ಉದ್ದೇಶಿಸಿರುವ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮುದ್ರಿಸಿ ಮತ್ತು ನೀವು ಬದಲಿಸಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸುವ ಕ್ಷೇತ್ರಗಳನ್ನು ದೃಢೀಕರಿಸಿ, ನಂತರ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಂರಚನೆ ಆ ಮಾರ್ಗಕ್ಕೆ ತೋರಿಸುತ್ತದೆ, ಬೇರೆಡೆಯ ನಕಲಿಗೆ ಅಲ್ಲ ಎಂದು ದೃಢೀಕರಿಸಿ.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)ಪ್ರಕ್ರಿಯೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳು ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. -config /etc/nebula/config.yml ರವಾನಿಸುವ ಘಟಕವು ಆ ಫೈಲ್‌ನ pki.cert ನಮೂದನ್ನು ಓದುತ್ತದೆ, ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಯಾವುದನ್ನೂ ಪ್ರಭಾವಿಸುವುದಿಲ್ಲ. ಚಾಲನೆಯಲ್ಲಿರುವ ಆದೇಶ ಸಾಲಿನಲ್ಲಿರುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ನೀವು ಅನುಸರಿಸಿದ ದಾಖಲೆಯ ಮಾರ್ಗವನ್ನಲ್ಲ. ಎರಡೂ ಭಿನ್ನವಾಗಿದ್ದರೆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮುಟ್ಟದೆಯೇ ನೀವು ಸಮಸ್ಯೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.
ಹೊಸ ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಬೇರೆ ವಿಳಾಸವಿದ್ದು ಪ್ರಕ್ರಿಯೆ ಹಳೆಯದನ್ನು ಉಳಿಸಿಕೊಂಡಿದ್ದರೆ, ಈಗ ನಿಮಗೆ ಒಗಟಿನ ಬದಲು ವಿವರಣೆ ಇದೆ. ಸ್ವೀಕಾರಾರ್ಹವಾದರೆ ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು ವಿಳಾಸ ಬದಲಾವಣೆಯನ್ನು ಆಕಸ್ಮಿಕವಲ್ಲದ, ಯೋಜಿತ ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆ ಎಂದು ಪರಿಗಣಿಸಿ.
ವಿಳಾಸ ಬದಲಾವಣೆ ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆ
ಯಂತ್ರವನ್ನು ಸರಿಸುವುದನ್ನು ಯೋಜಿಸುವಂತೆ ಇದನ್ನು ಯೋಜಿಸಿ. ಇತರ ಹೋಸ್ಟ್‌ಗಳು ಹಳೆಯ ವಿಳಾಸವನ್ನು ತಮ್ಮ ಸಂರಚನೆಯಲ್ಲಿ ಪಿನ್ ಮಾಡಿರಬಹುದು, ಸೇವೆಗಳು ಅದಕ್ಕೆ ಸ್ಪಷ್ಟವಾಗಿ ಬಂಧಿಸಿರಬಹುದು, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು ಅದರ ವಿರುದ್ಧ ಬರೆಯಲಾಗಿರಬಹುದು. ಪ್ರಮಾಣಪತ್ರ ಬದಲಿಸುವುದು ಹೋಸ್ಟ್ ಅನ್ನು ಸರಿಸುತ್ತದೆ, ಮತ್ತು ಹೋಸ್ಟ್ ಸರಿಸುವುದು ಬೇರೆಡೆಯ ಊಹೆಗಳನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ.
ಇದನ್ನು ಮಾಡುವಾಗ ಎರಡನೇ ನಿರ್ವಹಣಾ ಮಾರ್ಗವನ್ನು ಲಭ್ಯವಾಗಿಡಿ, ಏಕೆಂದರೆ ನೀವು ಅಡ್ಡಿಪಡಿಸುತ್ತಿರುವುದು overlay ಸಂಪರ್ಕವೇ ಆಗಿರಬಹುದು. ನೀವು ಮುರಿಯಲಿರುವ ಸುರಂಗದ ಮೇಲೆಯೇ ಇದನ್ನು ಮಾಡುವುದು ಐದು ನಿಮಿಷದ ಬದಲಾವಣೆಯನ್ನು ಸ್ಥಳ ಭೇಟಿಯಾಗಿ ಪರಿವರ್ತಿಸುವ ಸಾಂಪ್ರದಾಯಿಕ ದಾರಿ.
ಮರುಪ್ರಾರಂಭ ಸ್ವೀಕಾರಾರ್ಹವೇ ಎಂಬುದು ಹೋಸ್ಟ್ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಅದು ತಾಂತ್ರಿಕವಲ್ಲದ, ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಶ್ನೆ. ಐಚ್ಛಿಕವಲ್ಲದ್ದು ಎಂದರೆ ಮರುಲೋಡ್ ಅನ್ನು ಐದನೇ ಬಾರಿ ಕಳುಹಿಸುವ ಬದಲು ಮರುಪ್ರಾರಂಭದ ಅಗತ್ಯವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು.
ಹಳೆಯ ರುಜುವಾತನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನಿವೃತ್ತಿಗೊಳಿಸಿ
ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ಬದಲಿಯನ್ನು ಸ್ಥಾಪಿಸಿದರೆ ಪ್ರತಿ ಪೀರ್ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ರುಜುವಾತನ್ನು ಇನ್ನೂ ನಂಬುತ್ತದೆ. ಬದಲಾವಣೆಯ ಕಾರಣ ಒಡೆತನವಾಗಿದ್ದರೆ, ಹಳೆಯ ಗುರುತನ್ನು ನಂಬಿಕೆ ಅಥವಾ ಬ್ಲಾಕ್‌ಲಿಸ್ಟ್ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ನಿವೃತ್ತಿಗೊಳಿಸಬೇಕು, ಆಗ ಪೀರ್ ಅದನ್ನು ನಿಜವಾಗಿ ತಿರಸ್ಕರಿಸುತ್ತದೆ.
ಇದು ತನ್ನದೇ ಪರಿಶೀಲನೆಯನ್ನು ಹೊಂದಿರುವ ಪ್ರತ್ಯೇಕ ಹಂತ: ಹೊಸ ಫೈಲ್ ಕೆಲಸ ಮಾಡಿತು ಎಂದು ಭಾವಿಸುವ ಬದಲು, ಹಳೆಯ ಗುರುತು ಇನ್ನು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಇನ್ನೊಂದು ಹೋಸ್ಟ್‌ನಿಂದ ದೃಢೀಕರಿಸಿ. Nebula PKI ಸಂರಚನಾ ದಾಖಲೆ ಮರುಲೋಡ್ ಮಾಡಬಹುದಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮತ್ತು ಇಲ್ಲಿ ವಿವರಿಸಿದ ವಿಳಾಸ ಮಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ, ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಯಾವುದನ್ನೂ ರೊಟೇಟ್ ಮಾಡುವ ಮೊದಲು ಅದನ್ನು ಪೂರ್ಣವಾಗಿ ಓದುವುದು ಯೋಗ್ಯ.