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 ਸੰਰਚਨਾ ਦਸਤਾਵੇਜ਼ ਮੁੜ ਲੋਡ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਸੈਟਿੰਗਾਂ ਅਤੇ ਇੱਥੇ ਦੱਸੀ ਪਤਾ ਹੱਦ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਤਪਾਦਨ ਨਾਲ ਜੁੜੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਰੋਟੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਪੂਰਾ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ।