OpenConnect ਨੂੰ ਟੁੱਟੇ VPN ਨਾਲ ਦੁਬਾਰਾ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਿੰਨੀ ਦੇਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?

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

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

ਮੁੜ-ਜੁੜਾਈ ਵਿੰਡੋ ਅਸਲ ਵਿੱਚ ਕੀ ਸੀਮਿਤ ਕਰਦੀ ਹੈ

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

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

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

ਸੁਪਰਵਾਈਜ਼ਰ ਦੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਅਤੇ ਕਲਾਇੰਟ ਦੀਆਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਦੋ ਪਰਤਾਂ ਹਨ

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

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

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

ਹੈਂਡਓਫ਼ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਲੂਪ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਤੋਂ ਰੋਕਣਾ

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

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

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

ਰੁਕਾਵਟ ਦੌਰਾਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਹੈ

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

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

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