ਮਿਟਾਇਆ 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

ਆਪਣੇ ਆਪ ਹੋਸਟ ਕੀਤੇ ਕੰਟਰੋਲਰ ਲਈ ਉਸਦੀ ਪਛਾਣ ਅਤੇ ਸੰਰਚਨਾ ਦਾ ਸੁਸੰਗਤ ਬੈਕਅਪ ਰੱਖੋ। ਪਿਛਲੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਜਾਣ ਵਾਲਾ ਬਹਾਲੀ ਪੁਰਾਣਾ ਅਧਿਕਾਰ ਵੀ ਨਾਲ ਲੈ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੈਂਬਰ ਸੂਚੀ ਰਿਟਾਇਰ ਤੋਂ ਪਹਿਲਾਂ ਵਰਗੀ ਹੀ ਦਿਸੇਗੀ।

ਪੁਰਾਣੀ ਪਛਾਣ ਕਿਤੇ ਵੀ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀ ਅਤੇ ਰਿਕਾਰਡ ਚਲਾ ਗਿਆ ਹੈ ਤਾਂ ਰਿਟਾਇਰ ਪੂਰਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਕੰਮ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ, ਮੈਂਬਰ ਵਾਪਸ ਆਉਣਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ।