ಅಳಿಸಿದ ZeroTier ಸದಸ್ಯ ಮತ್ತೆ ಬರುತ್ತದೆ: ಮೊದಲು ಅನುಮತಿ ರದ್ದುಮಾಡಿ

ನೀವು ಸದಸ್ಯರನ್ನು ಅಳಿಸುತ್ತೀರಿ, ಪುಟವನ್ನು ಮುಚ್ಚುತ್ತೀರಿ, ಮತ್ತು ಒಂದು ದಿನದ ನಂತರ ಅದೇ ಸಾಧನ ಮತ್ತೆ ಬಂದಿದೆ. ಇದು ಕನ್ಸೋಲ್‌ನ ದೋಷವಲ್ಲ. ಸಾಧನವು ಇನ್ನೂ ಆನ್‌ಲೈನ್‌ನಲ್ಲಿದ್ದು ಇನ್ನೂ ಸೇರಲು ಕೇಳುತ್ತಿರುವಾಗ ದಾಖಲೆಯನ್ನು ಅಳಿಸಿದಾಗ ಇದೇ ಸಂಭವಿಸುತ್ತದೆ.

ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳು ಪಕ್ಕಪಕ್ಕವಿದ್ದು ಬೇರೆ ಬೇರೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಒಂದು ಪ್ರವೇಶವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ಪಟ್ಟಿಯನ್ನು ಮಾತ್ರ ಜೋಡಿಸುತ್ತದೆ.

ಮತ್ತೆ ಬರುವ ದಾಖಲೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ

ನೆಟ್‌ವರ್ಕ್ ತೆರೆದು ಮರಳಿ ಬಂದ ನಮೂದನ್ನು ನೋಡಿ. ಅದರ node ID, ಕೊನೆಯ ವಿಳಾಸ ಮತ್ತು ಮತ್ತೆ ಯಾವಾಗ ಕಾಣಿಸಿಕೊಂಡಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ನೀವು ನಿವೃತ್ತಿಗೊಳಿಸಲು ಉದ್ದೇಶಿಸಿದ್ದ ಸಾಧನದೊಂದಿಗೆ ಹೋಲಿಸಿ. ತೋರಿಸುವ ಹೆಸರು ಯಾರೋ ಟೈಪ್ ಮಾಡಿದ್ದು, ಮತ್ತು ಮುಂದಿನ ಸೇರುವಿಕೆಯಲ್ಲಿ ವಿಳಾಸ ಬದಲಾಗಬಹುದು.

node ID ಸ್ಥಿರ ಗುರುತಿಸುವಿಕೆಯಾಗಿದೆ. ನೆಟ್‌ವರ್ಕ್ ID ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಹೆಸರು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಯಾವ ಪಟ್ಟಿಯನ್ನು ಓದುತ್ತಿದ್ದೀರಿ ಎಂದು ಹೇಳುತ್ತದೆ, ಅದರಲ್ಲಿ ಯಾವ ಸಾಧನವಿದೆ ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ. ಎರಡನ್ನೂ ದಾಖಲಿಸಿ, ನಂತರ node ID ಅನ್ನು ನೀವು ನಿವೃತ್ತಿಗೊಳಿಸಲು ಉದ್ದೇಶಿಸಿದ್ದ ಯಂತ್ರದೊಂದಿಗೆ ಹೊಂದಿಸಿ.

ಈ ಹೋಲಿಕೆಯಲ್ಲಿ ತಪ್ಪಾದರೆ, ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಯಂತ್ರವನ್ನು ತೆಗೆದುಹಾಕುತ್ತೀರಿ, ಅನಪೇಕ್ಷಿತ ಸಾಧನವು ಕೇಳುತ್ತಲೇ ಇರುತ್ತದೆ. ಆಗ ಪಟ್ಟಿ ಒಂದು ದಿನ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ. ಯಾರಿಗೂ ಗಮನಕ್ಕೆ ಬಾರದಷ್ಟು ಸಮಯ ಇದು ಸಾಕು, ಮತ್ತು ಸಮಸ್ಯೆ ನಿಖರವಾಗಿ ಅಲ್ಲಿಯೇ ಇದೆ.

ಅಳಿಸುವ ಮೊದಲು ರದ್ದುಮಾಡಿ

ಮೊದಲು ನಿಯಂತ್ರಕವು ಬೆಂಬಲಿಸುವ ಕಾರ್ಯಪ್ರವಾಹದ ಮೂಲಕ ಅನುಮತಿ ಸ್ಥಿತಿಯನ್ನು ಬದಲಿಸಿ. ಆ ಕ್ಷಣದಿಂದ ಸೇರುವ ಪ್ರಯತ್ನವು ಪ್ರವೇಶವನ್ನು ಮೌನವಾಗಿ ಮರುಸ್ಥಾಪಿಸುವ ಬದಲು ಅನಧಿಕೃತ ಎಂದು ಕಾಣಿಸುತ್ತದೆ, ಮತ್ತು ವಿನಂತಿ ಅದೃಶ್ಯವಾಗಿರುವ ಬದಲು ಗೋಚರವಾಗುತ್ತದೆ.

ಅಳಿಸುವಿಕೆ ನಂತರ ಬರುತ್ತದೆ, ಎಂದಿಗೂ ಅದರ ಬದಲಿಗೆ ಅಲ್ಲ. ಅಧಿಕೃತ ಸದಸ್ಯರ ದಾಖಲೆಯನ್ನು ತೆಗೆದರೆ ರದ್ದುಮಾಡಲು ಏನೂ ಉಳಿಯುವುದಿಲ್ಲ. ಸಾಧನ ಮತ್ತೆ ಕೇಳುತ್ತದೆ, ಮತ್ತು ನಿಯಂತ್ರಕ ಅದನ್ನು ಹೊಸದೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ.

ನೀವು ಇನ್ನೂ ನಿಯಂತ್ರಿಸುತ್ತಿರುವ ಯಂತ್ರಕ್ಕೆ ನೆಟ್‌ವರ್ಕ್ ಬಿಡುವುದು ನಿವೃತ್ತಿಯ ಉಪಯುಕ್ತ ಭಾಗ. ಕಳೆದುಹೋದ ಸಾಧನದ ಬಗ್ಗೆ ನಿರ್ವಾಹಕರ ನಿರ್ಧಾರಕ್ಕೆ ಇದು ಪರ್ಯಾಯವಲ್ಲ. ನೀವು ಇನ್ನು ನಿಯಂತ್ರಿಸದ ಕ್ಲೈಂಟ್ ತನಗೆ ಹೇಳಿದ್ದನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು.

ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳು ಎಲ್ಲಿವೆ

ಹೋಸ್ಟ್ ಮಾಡಿದ ನಿಯಂತ್ರಕದಲ್ಲಿ ಸದಸ್ಯರ ಪಟ್ಟಿ ಎರಡೂ ಕ್ರಿಯೆಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಅವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿ ಲೇಬಲ್ ಮಾಡುತ್ತದೆ. ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ ನಿಯಂತ್ರಕದಲ್ಲಿ ಅದೇ ವ್ಯತ್ಯಾಸ API ಮತ್ತು ಸ್ಥಳೀಯ ಸಂರಚನೆಯಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ, ಮತ್ತು ಗೊಂದಲ ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲಿಂದಲೇ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'

# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"

ಸದಸ್ಯರು ಎಂದಾದರೂ ನಿಜವಾಗಿ ಅನಧಿಕೃತರಾಗಿದ್ದರೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ಈ ಎರಡು ಕರೆಗಳು ಸಾಕು. authorized: true ಜೊತೆಗೆ ಪದೇ ಪದೇ ಮರಳಿ ಬರುವ ದಾಖಲೆಯ ಅನುಮತಿ ಎಂದಿಗೂ ರದ್ದಾಗಿರಲಿಲ್ಲ; ಅದನ್ನು ಕೇವಲ ಅಳಿಸಲಾಗಿತ್ತು.

ಪಟ್ಟಿಯಿಂದ ಅಲ್ಲ, ಸಂಪನ್ಮೂಲದಿಂದ ದೃಢೀಕರಿಸಿ

ಜೋಡಿಸಿದ ಸದಸ್ಯರ ಪಟ್ಟಿ ಪ್ರವೇಶ ಪರಿಶೀಲನೆಯಲ್ಲ. ಸಾಧನವು ಹಿಂದೆ ಬಳಸಿದ ಸಂಪನ್ಮೂಲವನ್ನು ಅದೇ ಸಾಧನದಿಂದ ಅಥವಾ ಅದರ ಹಳೆಯ ವಿಳಾಸವಿರುವ ಯಂತ್ರದಿಂದ ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಸಂಪರ್ಕ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ನಂತರ ಅನುಮೋದಿತ ಬದಲಿಯು ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

ಆ ಪರೀಕ್ಷೆಯಲ್ಲಿ ರೂಟ್‌ಗಳು ಮತ್ತು ಸೇವಾ ಅನುಮತಿಗಳನ್ನು ಸೇರಿಸಿ. ZeroTier ಸದಸ್ಯರಿಗೆ ಅನುಮತಿ ನೀಡಿಯೂ ನಿರ್ವಹಿತ ರೂಟ್ ತಲುಪಲು ಸಾಧ್ಯವಾಗದಂತೆ ಬಿಡಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿಯೂ ಅದೇ ರೀತಿ ವಿಫಲವಾಗಬಹುದು. ಸದಸ್ಯರ ಪಟ್ಟಿಯಿಂದ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ ನಿಯಂತ್ರಕಕ್ಕೆ ಅದರ ಗುರುತು ಮತ್ತು ಸಂರಚನೆಯ ಸುಸಂಗತ ಬ್ಯಾಕಪ್ ಇಟ್ಟುಕೊಳ್ಳಿ. ಹಿಂದಿನ ಸ್ಥಿತಿಗೆ ಮರಳುವ ಮರುಸ್ಥಾಪನೆಯು ಹಳೆಯ ಅನುಮತಿಯನ್ನೂ ಜೊತೆಗೆ ತರಬಹುದು, ಮತ್ತು ಸದಸ್ಯರ ಪಟ್ಟಿ ನಿವೃತ್ತಿಗೆ ಮೊದಲಿನಂತೆಯೇ ಕಾಣುತ್ತದೆ.

ಹಳೆಯ ಗುರುತು ಯಾವುದನ್ನೂ ತಲುಪಲಾಗದಿದ್ದಾಗ ಮತ್ತು ದಾಖಲೆ ಹೋದಾಗ ನಿವೃತ್ತಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ. ಇವನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಮಾಡಿ, ಸದಸ್ಯ ಮರಳಿ ಬರುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.