ਫਾਇਰਵਾਲ ਪੈਕੇਜ ਇੰਸਟਾਲ ਹੋਇਆ, ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਨਿਯਮ ਗਾਇਬ

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

ਲੱਛਣ ਅਸਲ ਵਿੱਚ ਕੀ ਦੱਸਦਾ ਹੈ

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

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

ਪੈਕੇਜ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਕੇ ਸ਼ੁਰੂ ਨਾ ਕਰੋ।

ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਸਥਿਰਤਾ ਸੰਦ ਪੜ੍ਹੋ

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

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

ਕੀ ਲੋਡ ਹੈ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੰਭਾਲੋ।

ਤੈਅ ਕਰੋ ਕਿ ਕੀ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

ਜਵਾਬ ਨੀਤੀ ਤੈਅ ਕਰਦੀ ਹੈ, ਪੈਕੇਜ ਨਹੀਂ।

ਬਹਾਲੀ ਦਾ ਕ੍ਰਮ ਜਾਂਚੋ

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

systemctl status netfilter-persistent
iptables -S

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

ਕ੍ਰਮ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਦਾ ਗੁਣ ਹੈ, ਡਿਸਕ 'ਤੇ ਪਈ ਫਾਈਲ ਦਾ ਨਹੀਂ।

ਤਿੰਨ ਵੱਖਰੇ ਨਤੀਜੇ ਸਵੀਕਾਰੋ

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

nft list ruleset

ਫਿਰ ਇਜਾਜ਼ਤ ਵਾਲੀ ਕਿਰਿਆ ਅਤੇ ਲਾਜ਼ਮੀ ਇਨਕਾਰ ਦੀ ਪਰਖ ਕਰੋ।

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