OpenVPN client-connect ਅਸਫਲਤਾ: ਕੀ disconnect ਸਮੇਂ ਸਫਾਈ ਦੀ ਗਾਰੰਟੀ ਹੈ?
ਰੱਦ ਕੀਤਾ ਕਲਾਇੰਟ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ ਲਿਖਿਆ ਰਿਕਾਰਡ ਵਾਪਸ ਨਹੀਂ ਲੈਂਦਾ। ਕਾਲਬੈਕ ਕਰਾਰ ਦੀ ਤੁਲਨਾ ਉਸ ਰੋਲਬੈਕ ਨਾਲ ਕਰੋ ਜੋ ਤੁਹਾਡੇ hook ਨੂੰ ਖੁਦ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਜਦੋਂ client-connect ਸਕ੍ਰਿਪਟ ਗੈਰ-ਸਿਫ਼ਰ ਕੋਡ ਨਾਲ ਬਾਹਰ ਨਿਕਲਦੀ ਹੈ, OpenVPN ਕਲਾਇੰਟ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਆਪਰੇਟਰ ਆਮ ਤੌਰ ’ਤੇ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਸੰਬੰਧਿਤ client-disconnect ਸਕ੍ਰਿਪਟ ਸਭ ਠੀਕ ਕਰ ਦੇਵੇਗੀ। ਅਕਸਰ ਉਹ ਕਦੇ ਚੱਲਦੀ ਹੀ ਨਹੀਂ, ਕਿਉਂਕਿ disconnect ਪ੍ਰੋਸੈਸਿੰਗ ਇਸ ’ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ connect ਪੜਾਅ ਕੀ ਪੂਰਾ ਕਰ ਸਕਿਆ। ਰੱਦ ਕਰਨ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਇੱਕੋ ਕਾਰਵਿਧੀ ਮੰਨਣਾ ਹੀ ਅਸਫਲ ਲੌਗਇਨ ਨੂੰ ਲੀਕ ਹੋਏ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ ਅਨਾਥ ਰਿਕਾਰਡ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਇਹ ਦੋ ਵੱਖਰੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਸਵੈਚਾਲਿਤ ਹੈ। ਸਰਵਰ ’ਤੇ ਸਥਿਤੀ ਛੱਡਣ ਦਾ ਦੋਸ਼ ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ hook ਦਾ ਆਪਣਾ ਨਿਕਾਸ ਮਾਰਗ ਪੜ੍ਹੋ।
ਗੈਰ-ਸਿਫ਼ਰ ਨਿਕਾਸ ਕਲਾਇੰਟ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ; ਇਹ ਤੁਹਾਡਾ ਕੰਮ ਵਾਪਸ ਨਹੀਂ ਲੈਂਦਾ
client-connect ਦੀ ਨਿਕਾਸ ਸਥਿਤੀ ਦਾਖਲੇ ਦਾ ਫ਼ੈਸਲਾ ਹੈ। ਸਿਫ਼ਰ ਦਾ ਮਤਲਬ ਦਾਖਲਾ, ਬਾਕੀ ਕੁਝ ਵੀ ਦਾ ਮਤਲਬ ਇੰਸਟੈਂਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਥਾਪਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਢਾਹੁਣਾ। ਉਸ ਕਰਾਰ ਵਿੱਚ ਕੁਝ ਵੀ ਇਹ ਨਹੀਂ ਜਾਂਚਦਾ ਕਿ ਸਕ੍ਰਿਪਟ ਬਾਹਰੀ ਦੁਨੀਆ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਕੀ ਕਰ ਚੁੱਕੀ ਹੈ। ਜੇ ਸਕ੍ਰਿਪਟ ਨੇ iptables ਨਿਯਮ ਜੋੜਿਆ, ਲਾਈਨ ਲਿਖੀ ਜਾਂ ਕਾਊਂਟਰ ਵਧਾਇਆ, ਤਾਂ ਉਹ ਬਦਲਾਅ ਰੱਦ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿੰਦੇ ਹਨ।
ਇਹੋ ਅਸਮਾਨਤਾ ਪਲੱਗਇਨਾਂ ’ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਇੰਸਟੈਂਸ ਲਈ ਕਈ connect ਫੰਕਸ਼ਨ ਚੱਲ ਸਕਦੇ ਹਨ। ਬਾਅਦ ਦੀ ਅਸਫਲਤਾ ਪਿਛਲੀ ਸਫਲਤਾ ਨੂੰ ਪਿਛੇਤਰ ਤੌਰ ’ਤੇ ਰੱਦ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਪਿਛਲੇ ਫੰਕਸ਼ਨ ਕੋਲ ਇਹ ਜਾਣਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਕਿ ਭੈਣ ਫੰਕਸ਼ਨ ਅਸਫਲ ਹੋਇਆ।
ਰੱਦ ਕਰਨਾ ਸਵੈਚਾਲਿਤ ਹੈ, ਸਫਾਈ ਨਹੀਂ
OpenVPN 2.6 ਦਸਤਾਵੇਜ਼ client-disconnect ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਪਿਛਲੀ connect ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਸਫਲਤਾ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਅਪਵਾਦ ਕੈਸਕੇਡ ਲੜੀਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ: ਜੇ ਇੱਕ connect ਕਦਮ ਪਹਿਲਾਂ ਹੀ ਸਫਲਤਾ ਵਾਪਸ ਕਰ ਚੁੱਕਾ ਹੈ, ਤਾਂ ਬਾਅਦ ਦਾ connect ਕਦਮ ਅਸਫਲ ਹੋਣ ’ਤੇ ਵੀ ਇੰਸਟੈਂਸ ਢਾਹੁੰਦੇ ਸਮੇਂ ਸੰਬੰਧਿਤ disconnect ਕਦਮ ਫਿਰ ਵੀ ਚੱਲਦੇ ਹਨ। ਉਹ ਅਪਵਾਦ ਤੰਗ ਹੈ ਅਤੇ ਇਸ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕਿੰਨੇ ਕਾਲਬੈਕ ਸੰਰਚਿਤ ਹਨ, ਇਸ ਲਈ ਇੱਕ shell ਸਕ੍ਰਿਪਟ ਦੀ ਜਾਂਚ ਤੁਹਾਨੂੰ ਲੜੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।
ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਸੰਰਚਨਾ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ: ਕਿਹੜੀ ਸਕ੍ਰਿਪਟ, ਕਿਹੜਾ ਪਲੱਗਇਨ ਅਤੇ ਕਿਹੜੇ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਦੱਸਦੀ ਹੈ ਕਿ ਅਧੂਰਾ ਸੈੱਟਅੱਪ ਪਿੱਛੇ ਕੀ ਛੱਡਦਾ ਹੈ।
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
ਹਰ ਕਤਾਰ ਕਲਾਇੰਟ ਲਈ ਇੱਕੋ ਤਰ੍ਹਾਂ ਅਤੇ ਹੋਸਟ ਲਈ ਵੱਖਰੇ ਤਰ੍ਹਾਂ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ। ਕਲਾਇੰਟ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਹੋਇਆ, ਇਸ ਲਈ hook ਨੂੰ ਅਸਫਲਤਾ ਸਥਿਤੀ ਵਾਪਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣਾ ਕੀਤਾ ਵਾਪਸ ਲੈਣਾ ਪੈਂਦਾ ਹੈ।
ਅਸਫਲ ਹੋਈ ਸਕ੍ਰਿਪਟ ਦੇ ਅੰਦਰ ਹੀ ਮੁਆਵਜ਼ਾ ਦਿਓ
ਸਾਂਝੀ ਸਥਿਤੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਵੀ ਸੰਭਵ ਹੋਵੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ: ਸਰਟੀਫਿਕੇਟ ਦੇ ਖੇਤਰ, ਪਤੇ ਦੀ ਉਪਲਬਧਤਾ, ਉਹ ਸਮੂਹ ਜਿਸ ਨਾਲ ਕਲਾਇੰਟ ਸੰਬੰਧਿਤ ਹੈ। ਸਭ ਤੋਂ ਸਸਤਾ ਰੱਦ ਕਰਨਾ ਉਹ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਵੰਡ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਸੈੱਟਅੱਪ ਕਈ ਬਾਹਰੀ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਫੈਲ ਜਾਵੇ, ਤਾਂ ਰਿਕਾਰਡ ਰੱਖੋ ਕਿ ਕਿਹੜੀਆਂ ਪੂਰੀਆਂ ਹੋਈਆਂ ਅਤੇ ਅਸਫਲਤਾ ਸਥਿਤੀ ਵਾਪਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਉਲਟੇ ਕ੍ਰਮ ਵਿੱਚ ਵਾਪਸ ਲਵੋ।
ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ: ਸਕ੍ਰਿਪਟ ਹਰ ਕਲਾਇੰਟ ਲਈ ਫਾਇਰਵਾਲ ਐਂਟਰੀ ਬਣਾਉਂਦੀ ਹੈ, ਫਿਰ ਉਸ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੀ ਸਥਿਤੀ-ਕਤਾਰ ਲਿਖਣ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਅਸਫਲ ਸ਼ਾਖਾ ਨੂੰ ਹੁਣੇ ਬਣਾਈ ਐਂਟਰੀ ਹਟਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਫਿਰ ਗੈਰ-ਸਿਫ਼ਰ ਕੋਡ ਨਾਲ ਬਾਹਰ ਨਿਕਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹੀ disconnect ਘਟਨਾ ਦੀ ਉਡੀਕ ਕਰਨਾ ਜੋ ਸ਼ਾਇਦ ਕਦੇ ਤਹਿ ਨਾ ਹੋਵੇ, ਇਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਨਿਯਮ ਆਪਣੇ ਮਕਸਦ ਵਾਲੇ ਸੈਸ਼ਨ ਤੋਂ ਵੱਧ ਜਿਉਂਦਾ ਰਹਿੰਦਾ ਹੈ।
ਮੁਆਵਜ਼ੇ ਨੂੰ ਇਡੈਂਪੋਟੈਂਟ ਅਤੇ ਮਾਲਕੀ ਵਾਲਾ ਬਣਾਓ
ਸਫਾਈ ਦੋ ਵਾਰ ਚਲਾਉਣ ਲਈ ਸੁਰੱਖਿਅਤ ਅਤੇ ਇਸ ਬਾਰੇ ਸਟੀਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਇਹ ਕੀ ਮਿਟਾ ਸਕਦੀ ਹੈ। ਪਿਛਲੇ ਯਤਨ ਦੀ ਦੇਰ ਨਾਲ ਆਈ ਘਟਨਾ ਨਵੇਂ ਸੈਸ਼ਨ ਦੀ ਵੰਡ ਨੂੰ ਸਿਰਫ਼ ਇਸ ਲਈ ਨਹੀਂ ਹਟਾਉਣੀ ਚਾਹੀਦੀ ਕਿ ਦੋਵੇਂ ਇੱਕ ਸਾਂਝਾ ਨਾਮ ਜਾਂ ਮੁੜ ਵਰਤਿਆ ਟਨਲ ਪਤਾ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਖਾਸ ਹੈਂਡਲ ਜਾਂ ਓਪਰੇਸ਼ਨ ਆਈਡੀ ਸਰੋਤ ਨਾਲ ਰਿਕਾਰਡ ਕਰੋ, ਅਤੇ ਨਾਮ ਨਾਲ ਨਹੀਂ, ਉਸੇ ਕੁੰਜੀ ਨਾਲ ਮਿਟਾਓ। ਡੇਟਾਬੇਸ ਲੈਣ-ਦੇਣ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਦੇ ਆਪਣੇ ਬਦਲਾਵਾਂ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ; ਉਸ ਹੱਦ ਤੋਂ ਬਾਹਰਲੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਈ ਸਪੱਸ਼ਟ ਮੁਆਵਜ਼ਾ ਕਦਮ ਚਾਹੀਦਾ ਹੈ।
ਮੰਨ ਲਓ ਕਿ ਪ੍ਰਕਿਰਿਆ ਬਦਲਾਅ ਅਤੇ ਸਫਾਈ ਦਰਮਿਆਨ ਮਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਸੁਲਾਹਕਾਰ ਜੋੜੋ ਜੋ ਸਮਾਂ-ਸਾਰਣੀ ਅਨੁਸਾਰ ਬਾਹਰੀ ਸਥਿਤੀ ਦੀ ਤੁਲਨਾ ਸਵੀਕਾਰ ਕੀਤੇ ਕਲਾਇੰਟ ਸੂਚੀ ਨਾਲ ਕਰਦਾ ਹੈ।
ਉਹ ਤਿੰਨ ਮਾਰਗ ਪਰਖੋ ਜੋ ਸੱਚਮੁੱਚ ਵੱਖਰੇ ਹਨ
ਤਿੰਨ ਹਾਲਤਾਂ ਦਾ ਅਭਿਆਸ ਕਰੋ: ਕੁਝ ਵੀ ਵੰਡੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਰੱਦ ਕਰਨਾ, ਅੰਸ਼ਿਕ ਵੰਡ ਤੋਂ ਬਾਅਦ ਰੱਦ ਕਰਨਾ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਆਮ ਸਵੀਕਾਰ ਕੀਤਾ ਸੈਸ਼ਨ। ਉਹ ਤਿੰਨ ਵੱਖਰੀਆਂ ਲੌਗ ਲਾਈਨਾਂ ਅਤੇ ਵੱਖਰੇ ਅਵਸ਼ੇਸ਼ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਹਰ ਇੱਕ ਤੋਂ ਬਾਅਦ ਬਾਹਰੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ, ਸਿਰਫ਼ ਕਲਾਇੰਟ ਦੇ ਅਸਫਲਤਾ ਸੁਨੇਹੇ ਦੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਦੋ ਵਿੱਚ ਕਲਾਇੰਟ ਦੀ ਅਸਫਲਤਾ ਹੀ ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ ਹੈ।
hook ਦਾ ਪੜਾਅ, ਨਿਕਾਸ ਸਥਿਤੀ ਅਤੇ ਕੀ ਵੰਡਿਆ ਜਾਂ ਛੱਡਿਆ ਗਿਆ, ਪਹਿਚਾਣ-ਪੱਤਰ ਛੱਡ ਕੇ ਲੌਗ ਕਰੋ। ਜੋ hook ਲੌਗ ਆਪਣੇ ਬਣਾਏ ਸਰੋਤ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਉਹੀ ਲੀਕ ਹੋਏ ਨਿਯਮ ਨੂੰ ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਲੱਭਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।