ਕਿੱਲ ਸਵਿੱਚ ਸਰਗਰਮ ਹੋਣ ’ਤੇ: ਖੁੱਲ੍ਹੇ TCP ਸੈਸ਼ਨਾਂ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ?

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

ਛੱਡਣਾ, ਅਸਵੀਕਾਰ ਕਰਨਾ ਅਤੇ ਰੀਸੈਟ ਕਰਨਾ ਵੱਖਰੇ ਹਨ

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

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

ਵਿਰਾਮ ਦੌਰਾਨ ਐਪਲੀਕੇਸ਼ਨ ਕੀ ਕਰਦੀ ਹੈ

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

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

ਫੈਸਲਾ ਕਰੋ ਕਿ ਰਿਕਵਰੀ ਲਾਜ਼ਮੀ ਹੈ ਜਾਂ ਨਹੀਂ

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

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

ਬਲੌਕ ਅਤੇ ਰਿਕਵਰੀ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੋ

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

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

ਰਿਕਵਰੀ ਦੇਖਦਿਆਂ ਨੁਕਸਾਨ ਰਹਿਤ ਜਾਂਚ ਕਾਰਵਾਈ ਵਰਤੋ, ਤਾਂ ਜੋ ਦੁਹਰਾਈ ਸਬਮਿਸ਼ਨ ਘਟਨਾ ਨਾ ਬਣ ਜਾਵੇ। ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਦੇਖਿਆ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਢੰਗ ਦਰਜ ਕਰੋ: ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਕੀ ਦਿਖਾਇਆ, ਸਾਕਟ ਬਚਿਆ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਉਹ ਆਪਣੇ ਆਪ ਕਦੋਂ ਠੀਕ ਹੋਇਆ।

ਉਮੀਦ ਕੀਤਾ ਵਿਵਹਾਰ ਲਾਗੂ ਨਿਯਮ ਦੇ ਕੋਲ ਲਿਖੋ ਅਤੇ ਤਾਰੀਖ਼ ਪਾਓ। ਉਸ ਨਿਯਮ ਨੂੰ ਬਦਲਣ ਵਾਲੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੈਨਾਤੀ ਨੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਹੜੇ ਸਮਝੌਤੇ ਦਾ ਵਾਅਦਾ ਕੀਤਾ ਸੀ।