ਆਪਣੇ ਆਪ ਨੂੰ ਬਾਹਰ ਲਾਕ ਕੀਤੇ ਬਿਨਾਂ ਫਾਇਰਵਾਲ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨਾ
ਨਿਯਮ ਲਾਗੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਰਿਕਵਰੀ ਰਾਹਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੋ, ਫਿਰ ਬਚੀ ਹੋਈ ਸੈਸ਼ਨ ਦੀ ਥਾਂ ਉਸ ਫਲੋ ਨਾਲ ਜਾਂਚੋ ਜਿਸ ਦਾ ਨਵੀਂ ਨੀਤੀ ਨੂੰ ਮੁਲਾਂਕਣ ਕਰਨਾ ਹੈ।
ਨਿਯਮ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਟਰਮੀਨਲ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਲੌਗਇਨ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਿਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਤੁਸੀਂ ਬਦਲ ਰਹੇ ਹੋ, ਉਸ ਉੱਤੇ ਫਾਇਰਵਾਲ ਤਬਦੀਲੀ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਸਾਰੀ ਮੁਸ਼ਕਲ ਇਹੀ ਖਾਲੀ ਥਾਂ ਹੈ। ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਇੱਕ ਵਾਰ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੇਖਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਸਥਾਪਿਤ ਫਲੋ ਹੀ ਉਹ ਇਕੱਲੀ ਜਾਂਚ ਹੈ ਜੋ ਨਵੀਂ ਨੀਤੀ ਨੂੰ ਵੇਖ ਨਹੀਂ ਸਕਦੀ। ਅੱਗੇ ਪਰਤਣ ਦੇ ਤਿੰਨ ਰਾਹਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਉਹ ਕ੍ਰਮ ਤੈਅ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਨਿਯਮ ਬਦਲਣ ਅਤੇ ਜਾਂਚਣੇ ਹਨ।
ਬਚੀ ਹੋਈ ਸੈਸ਼ਨ ਹੀ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਸਬੂਤ ਕਿਉਂ ਹੈ
ਸਟੇਟਫੁਲ ਫਾਇਰਵਾਲ ਫਲੋ ਦੇ ਪਹਿਲੇ ਪੈਕਟ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ ਅਤੇ ਐਂਟਰੀ ਦੇ ਜੀਵਤ ਰਹਿਣ ਤੱਕ ਉਹੀ ਫੈਸਲਾ ਰੱਖਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਜੋੜੇ ਗਏ ਨਿਯਮ ਉਨ੍ਹਾਂ ਫਲੋਆਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਜਿਸ ਵਿੰਡੋ ਵਿੱਚ ਤੁਸੀਂ ਟਾਈਪ ਕਰ ਰਹੇ ਹੋ ਉਹ ਵਰਤੋਂ ਯੋਗ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਬਾਕੀ ਸਾਰੇ ਰੱਦ ਹੁੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਤੁਸੀਂ ਜੋ ਸਿੱਖਦੇ ਹੋ ਉਹ ਉਸ ਨੀਤੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਕੁਝ ਮਿੰਟ ਪਹਿਲਾਂ ਲਾਗੂ ਸੀ। ਉਸੇ ਫਲੋ 'ਤੇ ਲਈ ਗਈ ਕੈਪਚਰ ਵੀ ਉਹ ਫੈਸਲਾ ਦਿਖਾਉਂਦੀ ਹੈ ਜੋ ਮਸ਼ੀਨ ਪਹਿਲਾਂ ਹੀ ਲੈ ਚੁੱਕੀ ਹੈ।
ਕੰਮ ਕਰ ਰਹੀ ਸੈਸ਼ਨ ਨੂੰ ਮਾਪ ਨਹੀਂ, ਸਗੋਂ ਐਮਰਜੈਂਸੀ ਨਿਕਾਸ ਮੰਨੋ। ਹਰ ਅਰਥਪੂਰਨ ਜਾਂਚ ਨੂੰ ਉਸ ਸਰੋਤ ਤੋਂ ਨਵਾਂ ਫਲੋ ਖੋਲ੍ਹਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਦਾ ਨਵਾਂ ਨਿਯਮ ਮੁਲਾਂਕਣ ਕਰੇਗਾ, ਅਤੇ ਪਹਿਲੀ ਜਾਂਚ ਉਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਦਾ ਅਸਫਲ ਹੋਣਾ ਸਭ ਤੋਂ ਵੱਧ ਦੁਖਦਾ ਹੈ। ਜਦੋਂ ਉਹੀ ਸੈਸ਼ਨ ਅੰਦਰ ਜਾਣ ਦਾ ਇਕੱਲਾ ਰਾਹ ਹੋਵੇ, ਤਦ ਤਬਦੀਲੀ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ।
ਪਰਤਣ ਦੇ ਤਿੰਨ ਰਾਹ, ਹਰ ਇੱਕ ਕਿਸ 'ਤੇ ਨਿਰਭਰ ਹੈ ਉਸ ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ
ਵਿਕਲਪਾਂ ਨੂੰ ਇਸ ਆਧਾਰ 'ਤੇ ਕ੍ਰਮਬੱਧ ਕਰੋ ਕਿ ਉਹ ਜਾਂਚ ਅਧੀਨ ਡਿਵਾਈਸ 'ਤੇ ਕਿੰਨਾ ਨਿਰਭਰ ਹਨ, ਕਿਉਂਕਿ ਨਿਯਮ ਗਲਤ ਸਾਬਤ ਹੋਣ 'ਤੇ ਤੁਸੀਂ ਉਸੇ ਕ੍ਰਮ ਨੂੰ ਫੜਦੇ ਹੋ। ਜੋ ਕੰਸੋਲ ਕਦੇ ਫਾਇਰਵਾਲ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਦਾ ਉਹ ਸੁਤੰਤਰ ਹੈ, ਅਭਿਆਸ ਕੀਤਾ ਰੋਲਬੈਕ ਲਗਭਗ ਉਹੀ ਹੈ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਖੁੱਲ੍ਹੀ ਸੈਸ਼ਨ ਉਹ ਨਹੀਂ ਹੈ।
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਕੰਸੋਲ ਰਾਹੀਂ ਲੌਗਇਨ ਕਰੋ ਅਤੇ ਸਾਬਤ ਕਰੋ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਜੋ ਆਊਟ-ਆਫ-ਬੈਂਡ ਰਾਹ ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਵਰਤਿਆ ਉਹ ਖਾਕਾ ਹੈ, ਵਿਕਲਪ ਨਹੀਂ। ਰੋਲਬੈਕ ਆਪਣੀ ਥਾਂ ਸਿਰਫ਼ ਉਸੇ ਪਲੇਟਫਾਰਮ 'ਤੇ, ਉਸੇ ਨਿਯਮਸੈਟ ਨਾਲ, ਮਨਜ਼ੂਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਾਲਣਾ ਕਰਕੇ ਕੀਤੇ ਅਭਿਆਸ ਤੋਂ ਬਾਅਦ ਹੀ ਕਮਾਉਂਦਾ ਹੈ, ਜੀਵਤ ਮਸ਼ੀਨ 'ਤੇ ਤੁਰੰਤ ਉਪਾਅ ਕਰਨ ਦੀ ਥਾਂ। ਕਦਮ ਲਿਖੋ ਅਤੇ ਕਿਸੇ ਹੋਰ ਨੂੰ ਉਹ ਪੜ੍ਹ ਕੇ ਸੁਣਾਉਣ ਲਈ ਕਹੋ। ਜੇ ਕ੍ਰਮ ਪੂਰਾ ਕਰਨ ਲਈ ਤੁਹਾਡੀ ਯਾਦਦਾਸ਼ਤ ਲੋੜੀਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਯੋਜਨਾ ਨਹੀਂ ਹੈ।
ਇੱਕ ਤਬਦੀਲੀ, ਫਿਰ ਇੱਕ ਕਨੈਕਸ਼ਨ ਜਿਸ ਦਾ ਮੁਲਾਂਕਣ ਹੋਣਾ ਹੈ
ਚੱਲ ਰਿਹਾ ਨਿਯਮਸੈਟ ਅਤੇ ਉਸ ਦੀ ਮਾਲਕ ਫਾਈਲ ਸੰਭਾਲੋ, ਫਿਰ ਇੱਕੋ ਸੰਕੀਰਣ ਸੋਧ ਕਰੋ। ਪ੍ਰਤੀ ਜਾਂਚ ਇੱਕ ਤਬਦੀਲੀ ਨਤੀਜੇ ਨੂੰ ਆਰੋਪਣਯੋਗ ਰੱਖਦੀ ਹੈ; ਇੱਕੋ ਸਮੇਂ ਦੋ ਕਰਨ ਨਾਲ ਚੱਲਦੀ ਮਸ਼ੀਨ ਅਤੇ ਇਹ ਪਤਾ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿ ਕਿਹੜੀ ਸੋਧ ਨੇ ਕੰਮ ਕੀਤਾ। ਜਿੱਥੇ ਪਲੇਟਫਾਰਮ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦਾ ਹੈ, ਉੱਥੇ ਪਹਿਲਾਂ ਉਹੀ ਕਰੋ, ਤਾਂ ਜੋ ਟਾਈਪਿੰਗ ਦੀ ਗਲਤੀ ਉਦੋਂ ਫੜੀ ਜਾਵੇ ਜਦੋਂ ਕੁਝ ਵੀ ਦਾਅ 'ਤੇ ਨਾ ਹੋਵੇ।
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf
ਫਿਰ ਕੰਸੋਲ ਦੇ ਜੁੜੇ ਰਹਿਣ ਸਮੇਂ, ਉਸ ਸਰੋਤ ਤੋਂ ਨਵੀਂ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ ਨਾਲ ਬਦਲਿਆ ਨਿਯਮ ਮੇਲ ਖਾਏਗਾ। ਸਫਲ ਹੋਵੇ ਤਾਂ ਇੱਕ ਵਾਰ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਉਸ ਐਂਟਰੀ 'ਤੇ ਪੈ ਸਕਦੀ ਹੈ ਜੋ ਟੇਬਲ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸੀ। ਅਸਫਲ ਹੋਵੇ ਤਾਂ ਅੰਦਰ ਜਾਣ ਦਾ ਰਾਹ ਅਤੇ ਵਾਪਸ ਲੈਣ ਦਾ ਫੈਸਲਾ ਦੋਵੇਂ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਉਪਲਬਧ ਸਭ ਤੋਂ ਸਸਤਾ ਮਾੜਾ ਨਤੀਜਾ ਹੈ।
ਕਾਊਂਟਰ, ਸਥਿਤੀ ਅਤੇ ਫਾਈਲ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ
ਤਿੰਨ ਨਿਰੀਖਣਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਇਕੱਲਾ ਭਰੋਸੇਯੋਗ ਲੱਗ ਸਕਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਦੋ ਬਾਰੇ ਤੁਹਾਨੂੰ ਭਰਮਾ ਸਕਦਾ ਹੈ। ਕਾਊਂਟਰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਹੁਣੇ ਬਣਾਇਆ ਫਲੋ ਉਸ ਨਿਯਮ ਤੱਕ ਪਹੁੰਚਿਆ ਜੋ ਤੁਸੀਂ ਸੋਧਿਆ। ਸਥਿਤੀ ਟੇਬਲ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਮਸ਼ੀਨ ਕਿਹੜੇ ਫਲੋਆਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਮੰਨਦੀ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਟੁੱਟਿਆ ਨਿਯਮ ਵੀ ਸਿਹਤਮੰਦ ਦਿਸ ਸਕਦਾ ਹੈ। ਸੰਭਾਲੀ ਫਾਈਲ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਅਗਲੇ ਰੀਲੋਡ ਤੋਂ ਬਾਅਦ ਡਿਵਾਈਸ ਕੀ ਕਰੇਗਾ, ਅਤੇ ਇਹ ਉਹ ਨਹੀਂ ਹੋ ਸਕਦਾ ਜੋ ਹੁਣ ਚੱਲ ਰਿਹਾ ਨਿਯਮਸੈਟ ਕਰ ਰਿਹਾ ਹੈ।
ss -tn state established
ਕਾਊਂਟਰਾਂ ਨੂੰ ਜੋੜ ਨਹੀਂ, ਸਗੋਂ ਡੈਲਟਾ ਵਜੋਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਮਹੱਤਵਪੂਰਨ ਇਕੱਲੀ ਸੰਖਿਆ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੇ ਜਾਂਚ ਫਲੋ ਨੇ ਹਿਲਾਈ। ਜਿਸ ਨਿਯਮ ਦਾ ਕਾਊਂਟਰ ਕਦੇ ਨਹੀਂ ਵਧਦਾ ਉਹ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਕਾਗਜ਼ 'ਤੇ ਕਿੰਨਾ ਵੀ ਸਹੀ ਦਿਸੇ। ਨਕਾਰ ਦੇ ਕੇਸ ਦੀ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਜਿਸ ਨੀਤੀ ਨੇ ਕਦੇ ਕੁਝ ਨਕਾਰਿਆ ਨਹੀਂ, ਉਸ ਨੇ ਕਦੇ ਸਾਬਤ ਨਹੀਂ ਕੀਤਾ ਕਿ ਉਹ ਉਹ ਨਕਾਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਰੋਕਣਾ ਚਾਹੁੰਦੇ ਸੀ। ਜਿਨ੍ਹਾਂ ਪਰਿਵਾਰਾਂ ਨੂੰ ਤੈਨਾਤੀ ਅਸਲ ਵਿੱਚ ਢੋਂਦੀ ਹੈ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵਿੱਚ ਇੱਕ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਜਾਓ, ਕਿਉਂਕਿ v4 ਨਿਯਮ v6 ਫਲੋ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਸੰਭਾਲੇ ਨਿਯਮਸੈਟ ਤੋਂ ਬਹਾਲ ਕਰੋ, ਫਿਰ ਫਾਈਲ ਨੂੰ ਮਿਲਾਓ
ਜਦੋਂ ਤਬਦੀਲੀ ਅਸਫਲ ਹੋਵੇ, ਲੌਗਇਨ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨ ਤੱਕ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੇ ਨਿਯਮ ਜੋੜਨ ਦੀ ਥਾਂ ਸੰਭਾਲਿਆ ਨਿਯਮਸੈਟ ਲੋਡ ਕਰੋ। ਹਰ ਵਾਧੂ ਇਜਾਜ਼ਤ ਲੱਛਣ ਨੂੰ ਸ਼ਾਂਤ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਅਜਿਹਾ ਛੇਕ ਛੱਡਦੀ ਹੈ ਜੋ ਘਟਨਾ ਅਤੇ ਉਸ ਦੀ ਯਾਦ ਤੋਂ ਵੱਧ ਜੀਉਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਬਹਾਲ ਕਰੋ, ਦੁਬਾਰਾ ਜੁੜੋ, ਅਤੇ ਫਿਰ ਅਸਫਲ ਤੁਲਨਾ ਨੂੰ ਤੁਸੀਂ ਕੀ ਅਜ਼ਮਾਇਆ ਉਸ ਦੇ ਰਿਕਾਰਡ ਦੇ ਕੋਲ ਰੱਖੋ।
ਸਫਲ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ, ਡਿਸਕ 'ਤੇ ਮੌਜੂਦ ਫਾਈਲ ਚੱਲ ਰਹੇ ਨਿਯਮਸੈਟ ਦਾ ਵਰਣਨ ਕਰੇ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰੀਲੋਡ ਇਸਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜੋ ਜੀਵਤ ਨਿਯਮਸੈਟ ਆਪਣੀ ਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਤੋਂ ਭਟਕ ਗਿਆ ਹੈ ਉਹ ਅਗਲੇ ਰੀਬੂਟ ਲਈ ਵਿਛਾਇਆ ਜਾਲ ਹੈ।