ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਦਲਾਅ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ: ਨਿਯਮਾਂ ਦਾ ਕ੍ਰਮ ਅਤੇ ਕਨੈਕਸ਼ਨ ਦੀ ਸਥਿਤੀ

ਤੁਸੀਂ ਨਿਯਮ ਸੰਪਾਦਿਤ ਕੀਤਾ, ਨਿਯਮ-ਸਮੂਹ ਦੁਬਾਰਾ ਲੋਡ ਕੀਤਾ, ਅਤੇ ਟਨਲ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਵਿਵਹਾਰ ਕਰ ਰਹੀ ਹੈ। ਇਸ ਨਤੀਜੇ ਦੇ ਦੋ ਆਮ ਕਾਰਨ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਲਈ ਵੱਖਰੇ ਟੈਸਟ ਚਾਹੀਦੇ ਹਨ। ਜਾਂ ਤਾਂ ਨਵਾਂ ਨਿਯਮ ਪਹਿਲਾਂ ਹੀ ਪੈਕਟ ਸਵੀਕਾਰ ਕਰ ਚੁੱਕੇ ਪਿਛਲੇ ਨਿਯਮ ਤੋਂ ਬਾਅਦ ਹੈ, ਜਾਂ ਜੋ ਤਬਾਦਲਾ ਤੁਸੀਂ ਦੇਖ ਰਹੇ ਹੋ ਉਹ ਟ੍ਰੈਕ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਹੈ ਜਿਸਦਾ ਬਦਲਾਅ ਕਦੇ ਮੁੜ ਮੁਲਾਂਕਣ ਨਹੀਂ ਕਰਦਾ। ਫਾਈਲ ਵਿੱਚਲਾ ਨਿਯਮ ਇਰਾਦਾ ਦਰਸਾਉਂਦਾ ਹੈ; ਪੈਕਟ ਦਾ ਭਾਗਿਆ ਉਹ ਸਰਗਰਮ ਰਾਹ ਤੈਅ ਕਰਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਮਿਲਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਅਜਿਹਾ ਕਰਦਿਆਂ ਵਾਪਸੀ ਦਾ ਰਾਹ ਖੁੱਲ੍ਹਾ ਰੱਖੋ।

ਨਿਯਮਾਂ ਦਾ ਕ੍ਰਮ ਅਤੇ ਕਨੈਕਸ਼ਨ ਦੀ ਸਥਿਤੀ ਵੱਖਰੀਆਂ ਖਰਾਬੀਆਂ ਹਨ

ਕ੍ਰਮਬੱਧ ਚੇਨਾਂ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਮੁਲਾਂਕਣ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਅੰਤਿਮ ਫੈਸਲੇ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਪਹਿਲਾ ਨਿਯਮ ਉਸ ਚੇਨ ਵਿੱਚੋਂ ਲੰਘਣਾ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਧਿਆਨ ਨਾਲ ਲਿਖੇ ਲਾਕਡਾਊਨ ਨਿਯਮ ਉੱਤੇ ਚੌੜੀ ਮਨਜ਼ੂਰੀ ਰੱਖੋ, ਅਤੇ ਲਾਕਡਾਊਨ ਨਿਯਮ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਬਣ ਜਾਂਦਾ ਹੈ: ਇਹ ਨਿਯਮ-ਸਮੂਹ ਵਿੱਚ ਹੈ, ਇਸਦਾ ਕਾਊਂਟਰ ਸਿਫ਼ਰ ਹੈ, ਅਤੇ ਕੋਈ ਪੈਕਟ ਕਦੇ ਇਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੇਗਾ। ਉਹੀ ਪਾਠ ਕਿਸੇ ਹੋਰ ਚੇਨ ਉੱਤੇ ਲਾਗੂ ਕਰਨ ਨਾਲ ਵੀ ਕੁਝ ਸਿੱਧ ਨਹੀਂ ਹੁੰਦਾ। nftables ਵਿੱਚ ਅਧਾਰ ਚੇਨਾਂ ਤਰਜੀਹਾਂ ਉੱਤੇ ਹੁੱਕਾਂ ਨਾਲ ਜੁੜਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਚੇਨ ਵਿੱਚ ਮਨਜ਼ੂਰੀ ਦੂਜੇ ਹੁੱਕ ਜਾਂ ਤਰਜੀਹ ਵਾਲੀ ਦੂਜੀ ਚੇਨ ਨੂੰ ਉਹੀ ਪੈਕਟ ਦੇਖਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦੀ।

ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਦੂਜਾ ਲੱਛਣ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਬਾਹਰੋਂ ਇਹ ਬਿਲਕੁਲ ਉਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ। ਜਦੋਂ ਪ੍ਰਵਾਹ ਸਥਿਤੀ ਸਾਰਣੀ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ, ਚੇਨ ਦੇ ਉੱਪਰਲੇ ਹਿੱਸੇ ਨੇੜੇ established-or-related ਮਨਜ਼ੂਰੀ ਤੁਹਾਡੇ ਨਵੇਂ ਨਿਯਮ ਉੱਤੇ ਵਿਚਾਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ। NAT ਮੈਪਿੰਗ ਦਾ ਵੀ ਇਹੋ ਗੁਣ ਹੈ: ਪ੍ਰਵਾਹ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਅਨੁਵਾਦ ਤੈਅ ਹੋ ਚੁੱਕਾ ਸੀ, ਇਸ ਲਈ ਸੰਪਾਦਿਤ postrouting ਨਿਯਮ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਹੇ ਸੈਸ਼ਨ ਨੂੰ ਮੁੜ ਨਹੀਂ ਲਿਖਦਾ। ਇਸੇ ਲਈ ਬਦਲਾਅ 09:00 ਵਜੇ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਲਈ ਕੰਮ ਕਰਦਾ ਦਿਸਦਾ ਹੈ ਅਤੇ 08:55 ਵਜੇ ਕਿਸੇ ਵੱਲੋਂ ਖੋਲ੍ਹੇ ਸੈਸ਼ਨ ਲਈ ਕੁਝ ਨਾ ਕਰਦਾ ਦਿਸਦਾ ਹੈ।

ਕਲਾਊਡ ਸੁਰੱਖਿਆ ਸਮੂਹ ਤੀਜਾ ਮਾਡਲ ਜੋੜਦੇ ਹਨ ਜੋ iptables ਉੱਤੇ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਫੜਦਾ ਹੈ। ਉਹਨਾਂ ਦੇ ਇਨਬਾਊਂਡ ਨਿਯਮ ਮਨਜ਼ੂਰੀਆਂ ਦੀ ਸੂਚੀ ਹਨ ਜੋ ਪਹਿਲੀ ਮੇਲ ਦੀ ਚਾਲ ਦੀ ਥਾਂ ਸਮੂਹ ਵਜੋਂ ਮੁਲਾਂਕਣ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਉਹ ਸਥਿਤੀ ਵਾਲੇ ਹਨ, ਅਤੇ ਮਨਜ਼ੂਰੀ ਨਿਯਮ ਹਟਾਉਣ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਟ੍ਰੈਕ ਹੋ ਰਹੇ ਪ੍ਰਵਾਹ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ। ਜਿਸ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਪਹਿਲੀ ਮੇਲ ਦੀ ਭਾਸ਼ਾ ਨਹੀਂ ਹੈ ਉੱਥੇ ਇਸਨੂੰ ਮੰਨ ਲੈਣਾ ਭਰੋਸੇਯੋਗ ਪਰ ਗਲਤ ਸਿੱਟਿਆਂ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।

ਸਰਗਰਮ ਨਿਯਮ-ਸਮੂਹ ਪੜ੍ਹੋ, ਤੁਸੀਂ ਸੰਪਾਦਿਤ ਕੀਤੀ ਫਾਈਲ ਨਹੀਂ

ਕਰਨਲ ਇਸ ਵੇਲੇ ਕੀ ਲਾਗੂ ਕਰ ਰਿਹਾ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਕਦੇ ਲਾਗੂ ਨਾ ਕੀਤੀ ਸੰਭਾਲੀ ਸੰਰਚਨਾ ਹੈਰਾਨੀਜਨਕ ਤੌਰ ਤੇ ਕਈ ਅਣਬਦਲੇ ਵਿਵਹਾਰਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਬਾਹਰ ਕੱਢਣ ਲਈ ਇੱਕ ਹੀ ਕਮਾਂਡ ਲੱਗਦੀ ਹੈ:

nft list ruleset
iptables-save

ਫਿਰ ਪੁੱਛੋ ਕਿ ਤੁਹਾਡੇ ਨਿਯਮ ਤੱਕ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ। ਪੈਕਟ ਕਾਊਂਟਰ ਸਿੱਧਾ ਇਸਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਰਾਦੇ ਬਾਰੇ ਕਿਸੇ ਵੀ ਤਰਕ ਨਾਲੋਂ ਵਧੀਆ ਜਵਾਬ ਦਿੰਦੇ ਹਨ:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

ਅਸਲ ਟੈਸਟ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ ਸਿਫ਼ਰ ਪੈਕਟ ਵਾਲਾ ਲਾਕਡਾਊਨ ਨਿਯਮ ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ, ਇਹ ਸਥਾਨ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਇਸਨੂੰ ਹਿਲਾਉਣਾ ਇੱਕ ਲਾਈਨ ਦਾ ਬਦਲਾਅ ਹੈ, ਅਤੇ ਵਾਕ-ਰਚਨਾ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸਨੇ ਮੂਲ ਬੱਗ ਪੈਦਾ ਕੀਤਾ। iptables ਵਿੱਚ -I ਸ਼ੁਰੂ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ ਅਤੇ -A ਅੰਤ ਵਿੱਚ ਜੋੜਦਾ ਹੈ; nftables ਵਿੱਚ insert ਨਿਯਮ ਚੇਨ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਜਦਕਿ add ਅੰਤ ਵਿੱਚ ਜੋੜਦਾ ਹੈ। ਜਦੋਂ ਨਿਯਮ ਨੂੰ ਜਿੱਤਣਾ ਹੀ ਹੋਵੇ, ਤਾਂ ਸੰਜੋਗ ਨਾਲ ਲੋਡ ਹੋਏ ਕ੍ਰਮ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਇਹ ਸਪਸ਼ਟ ਕਹੋ।

ਪ੍ਰਵਾਹ ਟ੍ਰੈਕ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ ਸਿੱਧ ਕਰੋ

ਨਿਯਮ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ, ਜਾਂਚੋ ਕਿ ਟ੍ਰੈਫਿਕ ਅਸਲ ਵਿੱਚ ਟ੍ਰੈਕ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਹੈ ਜਾਂ ਨਹੀਂ। ਪੂਰੀ ਸਥਿਤੀ ਸਾਰਣੀ ਡੋਲ੍ਹਣ ਦੀ ਥਾਂ ਖਾਸ ਪ੍ਰਵਾਹ ਬਾਰੇ ਪੁੱਛੋ:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

ਸੂਚੀ ਸਥਿਤੀ ਅਤੇ ਬਾਕੀ ਸਮਾਂ-ਸੀਮਾ ਦਿਖਾਉਂਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਨੂੰ ਨਵੀਂ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹੋ; ਘਟਨਾ ਮੋਡ ਵਾਪਰਦਿਆਂ ਹੀ ਅੱਪਡੇਟ ਛਾਪਦਾ ਹੈ, ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਜੋੜਦਿਆਂ ਲਾਹੇਵੰਦ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਕੁਝ ਵੀ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਵਾਹ ਸਥਾਪਿਤ ਸਥਿਤੀ ਵਿੱਚ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਫਿਲਟਰ ਨਿਯਮਾਂ ਦਾ ਕੋਈ ਵੀ ਸੰਪਾਦਨ ਇਸਦਾ ਭਾਗਿਆ ਨਹੀਂ ਬਦਲੇਗਾ। ਇਹ ਫਾਇਰਵਾਲ ਵਿੱਚ ਬੱਗ ਨਹੀਂ, ਇਹ ਸਥਿਤੀ ਵਾਲੀ ਫਿਲਟਰਿੰਗ ਦਾ ਸਮਝੌਤਾ ਹੈ।

ਉਤਪਾਦਨ ਗੇਟਵੇ ਉੱਤੇ ਪੂਰੀ ਸਾਰਣੀ ਖਾਲੀ ਕਰਨ ਦੇ ਛੋਟੇ ਰਾਹ ਦਾ ਵਿਰੋਧ ਕਰੋ। conntrack -F ਉਪਲਬਧ ਹੈ, ਅਤੇ ਇਹ ਮਸ਼ੀਨ ਉੱਤੇ ਹਰ ਟ੍ਰੈਕ ਕੀਤੇ ਪ੍ਰਵਾਹ ਨੂੰ ਵੀ ਨਸ਼ਟ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਜਿਸ ਪ੍ਰਬੰਧਨ ਸੈਸ਼ਨ ਤੋਂ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਤੁਹਾਡਾ ਸ਼ੈੱਲ ਢੋਣ ਵਾਲੀ ਟਨਲ ਸ਼ਾਮਲ ਹੈ। ਸੱਚਮੁੱਚ ਲੋੜ ਪੈਣ ਉੱਤੇ ਵਿਅਕਤੀਗਤ ਐਂਟਰੀਆਂ ਮਿਟਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਨਵੇਂ ਸਰੋਤ ਪੋਰਟ ਤੋਂ ਨਵਾਂ ਪ੍ਰਵਾਹ ਆਮ ਤੌਰ ਤੇ ਵਧੇਰੇ ਸਾਫ਼ ਪ੍ਰਯੋਗ ਹੁੰਦਾ ਹੈ।

ਕੁਝ ਰਾਹ ਟ੍ਰੈਕ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਉਹ ਉਲਟਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। raw ਸਾਰਣੀ ਵਿੱਚ notrack ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਟ੍ਰੈਫਿਕ, ਆਮ ਹੁੱਕ ਟਾਲਣ ਵਾਲੀਆਂ ਕੁਝ ਟਨਲਾਂ, ਅਤੇ ਪ੍ਰਵਾਹ ਨੂੰ ਦੋ ਗੇਟਵੇ ਵਿਚਕਾਰ ਵੰਡਣ ਵਾਲਾ ਅਸਮਮਿਤ ਰੂਟਿੰਗ — ਸਭ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਮੁਲਾਂਕਣ ਹੋਣ ਵਾਲੇ ਪੈਕਟ ਜਾਂ ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ਕਦੇ ਨਾ ਬਣਨ ਵਾਲੀ ਸਥਿਤੀ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਜੇ ਹਰ ਪੈਕਟ ਉੱਤੇ ਕਾਊਂਟਰ ਹਿਲਦੇ ਹਨ, ਤਾਂ ਕ੍ਰਮ ਉੱਤੇ ਸ਼ੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਜਿਹੇ ਰਾਹ ਉੱਤੇ ਸ਼ੱਕ ਕਰੋ।

ਵਾਪਸੀ ਦੇ ਰਾਹ ਨਾਲ ਨਵੇਂ ਪ੍ਰਵਾਹ ਤੋਂ ਟੈਸਟ ਕਰੋ

ਦੂਰਸਥ ਪਹੁੰਚ ਕੱਟ ਸਕਣ ਵਾਲੇ ਨਿਯਮ ਦੀ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਬਹਾਲੀ ਦਾ ਰਾਹ ਬਣਾਓ: ਪ੍ਰਦਾਤਾ ਦਾ ਕੰਸੋਲ, ਸੀਰੀਅਲ ਕੰਸੋਲ, ਬੈਂਡ ਤੋਂ ਬਾਹਰਲਾ ਪ੍ਰਬੰਧਨ ਪਤਾ, ਜਾਂ ਦੂਜਾ ਇੰਟਰਫੇਸ ਜਿਸਨੂੰ ਨਿਯਮ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦਾ। ਰੋਲਬੈਕ ਟਾਈਮਰ ਢੁਕਵਾਂ ਸਾਥੀ ਹੈ, ਕਿਉਂਕਿ ਜੇ ਟੈਸਟ ਦੇ ਵਿਚਕਾਰ ਤੁਹਾਡਾ ਸੈਸ਼ਨ ਮਰ ਜਾਵੇ ਤਾਂ ਵੀ ਇਹ ਪਿਛਲਾ ਨਿਯਮ-ਸਮੂਹ ਬਹਾਲ ਕਰ ਦੇਵੇਗਾ।

ਫਿਰ ਅਜਿਹੇ ਤਬਾਦਲੇ ਨਾਲ ਟੈਸਟ ਕਰੋ ਜਿਸਨੂੰ ਸਥਿਤੀ ਪਹਿਲਾਂ ਹੀ ਢਕ ਨਹੀਂ ਸਕਦੀ ਸੀ। ਕਲਾਇੰਟ ਡਿਸਕਨੈਕਟ ਕਰਕੇ ਦੁਬਾਰਾ ਜੋੜੋ ਤਾਂ ਜੋ ਨਵਾਂ ਪੰਜਾਂ ਦਾ ਸਮੂਹ ਬਣੇ, ਅਤੇ ਇਹ ਹੁੰਦਿਆਂ ਦੋਵੇਂ ਸਿਰੇ ਵੇਖੋ:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

ਟੈਸਟ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਚਲਾਓ। ਨਵੀਂ ਇਨਬਾਊਂਡ ਹੈਂਡਸ਼ੇਕ ਰੋਕਣ ਵਾਲਾ ਨਿਯਮ ਜਵਾਬ ਦਾ ਰਾਹ ਅਜੇ ਵੀ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਉਲਟਾ ਵੀ, ਅਤੇ ਇੱਕ-ਦਿਸ਼ਾ ਨਤੀਜਾ ਹੀ ਲਾਕਡਾਊਨ ਦੇ ਅੱਧਾ ਕੰਮ ਕਰਨ ਦਾ ਆਮ ਕਾਰਨ ਹੈ। ਟੈਸਟ ਤੋਂ ਬਾਅਦ ਸਥਿਰ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਇੱਕ ਵਾਰ ਫਿਰ ਜੁੜੋ, ਅਤੇ ਵੇਖੋ ਕਿ ਜਾਇਜ਼ ਪ੍ਰਬੰਧਨ ਪਹੁੰਚ ਬਚੀ ਰਹੀ; ਇੱਕ ਪੋਰਟ ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਇਰਾਦੇ ਨਾਲੋਂ ਚੌੜੀ ਸੀਮਾ ਨਾਲ ਮੇਲ ਖਾਣ ਦੀ ਆਦਤ ਰੱਖਦਾ ਹੈ।

ਨਿਯਮ ਨਾਲ ਉਦੇਸ਼ ਅਤੇ ਸਥਾਨ ਦਰਜ ਕਰੋ

ਦਰਜ ਉਦੇਸ਼ ਤੋਂ ਬਿਨਾਂ ਨਿਯਮ ਉਹ ਨਿਯਮ ਹੈ ਜਿਸਨੂੰ ਹਟਾਉਣ ਦੀ ਹਿੰਮਤ ਕੋਈ ਨਹੀਂ ਕਰਦਾ। ਹਰ ਲਾਕਡਾਊਨ ਐਂਟਰੀ ਨਾਲ ਉਹ ਪ੍ਰਵਾਹ ਰੱਖੋ ਜਿਸਦੀ ਇਹ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਉਹ ਚੇਨ ਅਤੇ ਹੁੱਕ ਜਿਸ ਵਿੱਚ ਇਹ ਰਹਿੰਦਾ ਹੈ, ਚੌੜੀਆਂ ਮਨਜ਼ੂਰੀਆਂ ਦੇ ਮੁਕਾਬਲੇ ਰੱਖਣ ਵਾਲਾ ਸਥਾਨ, ਅਤੇ ਉਹ ਟੈਸਟ ਜਿਸਨੇ ਇਹ ਸਿੱਧ ਕੀਤਾ। ਜਦੋਂ ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਕੋਈ ਆਸਪਾਸ ਦਾ ਨਿਯਮ-ਸਮੂਹ ਸੰਪਾਦਿਤ ਕਰੇਗਾ, ਤਾਂ ਉਹ ਨੋਟ ਹੀ ਇਕੱਲੀ ਚੇਤਾਵਨੀ ਹੋਵੇਗੀ ਕਿ ਸਥਾਨ ਜਾਣਬੁੱਝ ਕੇ ਸੀ।

ਬਦਲਾਅ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਗੱਲਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਚੱਲ ਰਿਹਾ ਨਿਯਮ-ਸਮੂਹ ਫਾਈਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਨਵੀਂ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ ਨਵੇਂ ਨਿਯਮ ਦੇ ਕਾਊਂਟਰ ਸਿਫ਼ਰ ਨਹੀਂ ਹਨ, ਉਲਟੀ ਦਿਸ਼ਾ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪਹੁੰਚ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਬਦਲਾਅ ਤੋਂ ਪੁਰਾਣੇ ਸੈਸ਼ਨ ਦੀ ਸਥਿਤੀ ਨਹੀਂ, ਸਥਿਰ ਸਥਿਤੀ ਸਿੱਧ ਕਰਨ ਲਈ ਇੱਕ ਵਾਰ ਦੁਬਾਰਾ ਜੁੜੇ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਅਣਪੁਸ਼ਟ ਹੋਵੇ, ਤਾਂ ਟਨਲ ਕੁਝ ਵੀ ਕਰੇ, ਬਦਲਾਅ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ।