VPN ਸਾਈਟ ਤੋਂ 403 ਪ੍ਰਾਕਸੀ ਫੇਲ੍ਹ ਕਿਉਂ ਨਹੀਂ ਹੈ
ਮੂਲ ਤੋਂ 403, ਰੱਦ ਕੀਤਾ CONNECT ਅਤੇ 407 ਚੁਣੌਤੀ ਵੱਖਰੀਆਂ ਸੀਮਾਵਾਂ ਦਰਸਾਉਂਦੇ ਹਨ। ਪਹਿਲਾਂ ਪ੍ਰਾਕਸੀ ਦਾ ਨਿਕਾਸ ਮਾਰਗ ਬ੍ਰਾਊਜ਼ਰ ਦੇ VPN ਪਤੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਵਰਤੋਂਕਾਰ VPN ਬੰਦ ਕਰਦੇ ਹਨ, ਕਿਸੇ ਅੰਦਰੂਨੀ ਸਾਈਟ 'ਤੇ 403 ਮਿਲਦਾ ਹੈ ਅਤੇ ਦੱਸਦੇ ਹਨ ਕਿ ਪ੍ਰਾਕਸੀ ਖਰਾਬ ਹੈ। ਉਹ ਸਫ਼ਾ ਤਿੰਨ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਬਣਾ ਸਕਦੀਆਂ ਹਨ: ਮੂਲ ਨੇ ਬੇਨਤੀ ਰੱਦ ਕੀਤੀ, ਫਾਰਵਰਡ ਪ੍ਰਾਕਸੀ ਨੇ ਸੁਰੰਗ ਖੋਲ੍ਹਣ ਤੋਂ ਇਨਕਾਰ ਕੀਤਾ, ਜਾਂ ਪ੍ਰਾਕਸੀ ਨੇ ਆਪਣੇ ਪ੍ਰਮਾਣ ਮੰਗੇ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਸਹੀ ਜਵਾਬ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਆਮ ਫੇਲ੍ਹ ਸਫ਼ੇ ਵਿੱਚ ਸਮਤਲ ਕਰਨਾ ਤੁਹਾਡੇ ਕੋਲ ਮੌਜੂਦ ਇੱਕੋ ਇੱਕ ਸਬੂਤ ਨਸ਼ਟ ਕਰਦਾ ਹੈ। ਰੱਦ ਕਰਨ ਵਾਲੇ ਹਿੱਸੇ ਅਨੁਸਾਰ ਇਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰੋ, ਫਿਰ ਹਰ ਹਿੱਸੇ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਨੈੱਟਵਰਕ ਮਾਰਗ ਦੀ ਤੁਲਨਾ ਕਰੋ।
403 ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਹਿੱਸੇ ਦਾ ਨਾਮ ਦੱਸੋ
HTTP ਸਥਿਤੀ ਕੋਡ ਉਸ ਧਿਰ ਦਾ ਹੁੰਦਾ ਹੈ ਜਿਸਨੇ ਇਹ ਭੇਜਿਆ। ਜਦੋਂ ਮੂਲ 403 ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੇ ਬੇਨਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਕਾਲਰ ਕੋਲ ਸਰੋਤ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਇਹ ਅਧਿਕਾਰ ਦਾ ਜਵਾਬ ਹੈ, ਆਵਾਜਾਈ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ। ਜਦੋਂ ਫਾਰਵਰਡ ਪ੍ਰਾਕਸੀ CONNECT ਨੂੰ 403 ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਇਸਨੇ ਸੁਰੰਗ ਬਣਾਉਣ ਤੋਂ ਹੀ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ ਹੈ ਅਤੇ ਉੱਪਰ ਕਿਸੇ ਨਾਲ ਵੀ ਕਦੇ ਸੰਪਰਕ ਨਹੀਂ ਹੋਇਆ। ਜਦੋਂ ਇਹ 407 ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਆਪਣੇ ਪ੍ਰਮਾਣ ਚਾਹੁੰਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਦਾ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗਇਨ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ।
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 ਇਹਨਾਂ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਪ੍ਰਾਕਸੀ-ਵਿਸ਼ੇਸ਼ ਚੁਣੌਤੀ ਸਮੇਤ। ਮੁੱਖ ਭਾਗ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਦੀ ਆਪਣੀ ਸਥਿਤੀ ਅਤੇ ਕੋਈ ਵੀ Proxy-Authenticate ਹੈਡਰ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਦੋਸਤਾਨਾ HTML ਗਲਤੀ ਸਫ਼ਾ ਆਮ ਤੌਰ 'ਤੇ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਨੇ ਇਹ ਲਿਖਿਆ।
CONNECT ਸੁਰੰਗ ਬਾਈਟ ਰੀਲੇ ਤੋਂ ਕੀ ਲੁਕਾਉਂਦੀ ਹੈ
ਪ੍ਰਾਕਸੀ ਵੱਲੋਂ CONNECT ਨੂੰ 200 ਵਾਪਸ ਕਰਨ ਤੋਂ ਬਾਅਦ ਇਹ ਬਾਈਟ ਰੀਲੇ ਕਰ ਰਹੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਮੂਲ ਨਾਲ ਆਪਣਾ TLS ਸੈਸ਼ਨ ਰੱਖਦਾ ਹੈ। ਇਸ ਲਈ ਬਾਈਟ ਰੀਲੇ ਕਰਨ ਵਾਲੀ ਪ੍ਰਾਕਸੀ ਉਸ ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ 403 ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੀ, ਅਤੇ ਇਹ ਕਦੇ ਵੀ ਰੱਦ ਕਰਨ ਦੀ ਲੇਖਕ ਨਹੀਂ ਬਣਦੀ। ਸੁਰੰਗ ਖੁੱਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਇਨਕਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਘਟਨਾ ਹੈ, ਜੋ ਇੱਕ ਪਰਤ ਹੇਠਾਂ ਪੈਦਾ ਹੁੰਦੀ ਹੈ।
TLS ਖਤਮ ਕਰਨ ਵਾਲੀ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਵੱਖਰੀ ਸਥਿਤੀ ਵਿੱਚ ਹੈ: ਇਹ TLS ਸੀਮਾ ਦੀ ਮਾਲਕ ਹੈ, HTTP ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੀ ਹੈ ਅਤੇ ਜਵਾਬਾਂ ਨੂੰ ਜਾਇਜ਼ ਤੌਰ 'ਤੇ ਮੁੜ ਲਿਖ ਜਾਂ ਰੋਕ ਸਕਦੀ ਹੈ। ਇਹ ਸਮਰੱਥਾ ਸੰਰਚਨਾ ਦੀ ਚੋਣ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਾਕਸੀ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ, ਅਤੇ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪਹੁੰਚ ਨੀਤੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦੀ। ਜਵਾਬ ਪੜ੍ਹਨਾ ਇੱਕ ਸਮਰੱਥਾ ਹੈ; ਕਾਲਰ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰਨਾ ਮੂਲ ਦਾ ਕੰਮ ਹੀ ਰਹਿੰਦਾ ਹੈ।
ਵਿਹਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ 403 ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਤਿੰਨ ਰੂਪਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਚਲਾਉਂਦੇ ਹੋ। ਸਟ੍ਰੀਮ ਪ੍ਰਾਕਸੀ ਵਿੱਚ HTTP ਨਿਰੀਖਣ ਨਿਯਮ ਜੋੜਨ ਨਾਲ ਉਸਨੂੰ ਦ੍ਰਿਸ਼ਟਤਾ ਨਹੀਂ ਮਿਲਦੀ, ਅਤੇ ਬਾਈਟ ਰੀਲੇ ਤੋਂ ਮੂਲ ਦੇ ਇਨਕਾਰ ਦੀ ਵਿਆਖਿਆ ਦੀ ਉਮੀਦ ਕਰਨਾ ਤੁਹਾਨੂੰ ਗਲਤ ਲੌਗ ਵੱਲ ਭੇਜੇਗਾ।
ਪ੍ਰਾਕਸੀ ਦੇ ਨਿਕਾਸ ਮਾਰਗ ਦੀ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਸੁਰੰਗ ਪਤੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ
VPN ਨਾਲ ਜੁੜਿਆ ਬ੍ਰਾਊਜ਼ਰ ਆਪਣੇ ਆਪ ਵੱਖਰੇ ਪ੍ਰਾਕਸੀ ਸਰਵਰ ਨੂੰ ਉਸ ਸੁਰੰਗ 'ਤੇ ਨਹੀਂ ਲੈ ਜਾਂਦਾ। ਮੂਲ ਪ੍ਰਾਕਸੀ ਦਾ ਨਿਕਾਸ ਪਤਾ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਜੇ ਪ੍ਰਾਕਸੀ ਅਜੇ ਵੀ ਸਥਾਨਕ ਡਿਫਾਲਟ ਮਾਰਗ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸੁਰੱਖਿਅਤ ਸਾਈਟ ਉਹ ਪਤਾ ਦੇਖਦੀ ਹੈ ਜਿਸ 'ਤੇ ਕਦੇ ਭਰੋਸਾ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਲੈਪਟਾਪ ਦਾ ਅੰਦਰੂਨੀ VPN ਪਤਾ ਉਸ ਮੂਲ ਲਈ ਅਦਿੱਖ ਹੈ। ਕੰਮ ਕਰਦੀ ਸੁਰੰਗ ਵੀ ਅਜਿਹੀ ਸਾਈਟ ਤੋਂ 403 ਦਿੰਦੀ ਹੈ ਜੋ ਬਾਕੀ ਸਭ ਲਈ ਸਹੀ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ—ਇਹ ਇਸਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ।
ਪਤੇ ਉਲਝਣ ਨਾ ਜਾਣ ਲਈ ਦੋਵੇਂ ਮਾਰਗ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ।
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateਪਹਿਲੀ ਬੇਨਤੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਮੂਲ ਤੁਹਾਡੇ ਆਪਣੇ ਪਤੇ ਨੂੰ ਕੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਦੂਜੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪ੍ਰਾਕਸੀ ਦੇ ਪਤੇ ਨੂੰ ਕੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਮਿਲਦੀ 403 ਜੋੜੀ ਮੂਲ ਦੇ ਅਧਿਕਾਰ ਨਿਯਮਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ; 200 ਤੋਂ ਬਾਅਦ 403 ਆਉਣਾ ਪ੍ਰਾਕਸੀ ਮਾਰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। VPN ਪੂਲ ਸ਼ਾਮਲ ਹੈ ਮੰਨਣ ਦੀ ਬਜਾਏ ਮੂਲ ਦੇ ਮਾਲਕ ਨੂੰ ਪੁੱਛੋ ਕਿ ਨਿਯਮ ਸਮੂਹ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਸਰੋਤ ਪਤੇ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।
ਸੀਮਾ ਨੂੰ ਵੱਖ ਕਰਨ ਵਾਲੀ ਬੇਨਤੀ ਨਾਲ ਹਰ ਸੀਮਾ ਜਾਂਚੋ
ਪ੍ਰਾਕਸੀ ਪਰਤ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਨਾਂ ਕਰਕੇ ਰੱਦ ਨਾ ਕਰ ਸਕਣ ਵਾਲੀ ਚੀਜ਼ ਮੰਗ ਕੇ ਵੱਖ ਕਰੋ। ਜਿਸ ਹੋਸਟ ਤੱਕ ਪ੍ਰਾਕਸੀ ਨੂੰ ਪਹੁੰਚਣ ਦੀ ਆਗਿਆ ਹੈ, ਉਸ ਲਈ CONNECT, ਆਉਟਪੁੱਟ ਸੁੱਟ ਕੇ, ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਸੁਰੰਗ ਪ੍ਰਵੇਸ਼ ਬਿਲਕੁਲ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
ਜੇ ਇਹ CONNECT ਲਈ 200 ਅਤੇ ਫਿਰ TLS ਹੈਂਡਸ਼ੇਕ ਛਾਪਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਾਕਸੀ ਪ੍ਰਵੇਸ਼ ਠੀਕ ਹੈ ਅਤੇ ਬਾਅਦ ਵਾਲਾ 403 ਮੂਲ ਤੋਂ ਆਇਆ। ਜੇ ਇਹ 407 ਛਾਪਦਾ ਹੈ, ਤਾਂ --proxy-user ਨਾਲ ਪ੍ਰਾਕਸੀ ਪ੍ਰਮਾਣ ਦਿਓ ਅਤੇ ਸਾਈਟ ਬਾਰੇ ਕੋਈ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਦੁਹਰਾਓ। ਜੇ ਇਹ CONNECT ਲਾਈਨ 'ਤੇ 403 ਛਾਪਦਾ ਹੈ, ਤਾਂ ਜਾਂਚਣ ਵਾਲੀ ਸੀਮਾ ਪ੍ਰਾਕਸੀ ਦੀ ਆਪਣੀ ਆਗਿਆ ਸੂਚੀ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ।
ਪ੍ਰਮਾਣਾਂ ਨੂੰ ਸ਼ੈੱਲ ਇਤਿਹਾਸ ਅਤੇ ਪੇਸਟ ਕੀਤੀਆਂ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਤੋਂ ਦੂਰ ਰੱਖੋ। ਕਮਾਂਡ ਲਾਈਨ ਵਿੱਚ ਟਾਈਪ ਕੀਤਾ ਪ੍ਰਾਕਸੀ ਪਾਸਵਰਡ ਹੋਰ ਸਥਾਨਕ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਦਿਖਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਮਾਣਾਂ ਨਾਲ ਫੜਿਆ CONNECT ਨਿਸ਼ਾਨ ਕਿਸੇ ਵੀ ਨਿਸ਼ਾਨ ਤੋਂ ਬੁਰਾ ਹੈ।
ਸਫ਼ਾ ਮੁੜ ਲਿਖਣ ਦੀ ਬਜਾਏ ਫੈਸਲੇ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ
ਕਿਹੜੇ ਹਿੱਸੇ ਨੇ ਇਨਕਾਰ ਕੀਤਾ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਾਅਦ ਉਹ ਜਵਾਬ ਸੰਭਾਲੋ। ਜੋ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਮੂਲ ਦੇ 403 ਨੂੰ 504 ਟਾਈਮਆਊਟ ਵਜੋਂ ਮੁੜ ਲੇਬਲ ਕਰਦੀ ਹੈ, ਜਾਂ ਉਸਨੂੰ ਸਫਲਤਾ ਸਫ਼ੇ ਨਾਲ ਬਦਲਦੀ ਹੈ, ਉਹ ਅਧਿਕਾਰ ਦੇ ਫੈਸਲੇ ਨੂੰ ਉਪਲਬਧਤਾ ਦੀ ਕਹਾਣੀ ਪਿੱਛੇ ਲੁਕਾਉਂਦੀ ਹੈ ਅਤੇ ਅਗਲੇ ਜਵਾਬਦੇਹ ਨੂੰ ਗਲਤ ਟੀਮ ਕੋਲ ਭੇਜਦੀ ਹੈ। ਕਸਟਮ ਗਲਤੀ ਸਫ਼ੇ ਤਦ ਠੀਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਸਥਿਤੀ ਰੱਖਦੇ ਹਨ ਅਤੇ ਸੰਦਰਭ ਜੋੜਦੇ ਹਨ।
ਕੈਸ਼ਿੰਗ ਵੀ ਉਸੇ ਦੇਖਭਾਲ ਦੀ ਹੱਕਦਾਰ ਹੈ। RFC 9111 ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਸਾਂਝੇ ਕੈਸ਼ ਜਵਾਬਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਕਾਲਰ ਲਈ ਪੈਦਾ ਕੀਤਾ ਇਨਕਾਰ ਦੂਜੇ ਨੂੰ ਆਗਿਆ ਵਾਂਗ ਨਹੀਂ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ। ਜੇ ਇਨਕਾਰ ਜਵਾਬ ਕਿਸੇ ਤਰ੍ਹਾਂ ਸੰਗ੍ਰਹਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਨਿੱਜੀ ਅਤੇ ਸੀਮਿਤ ਰੱਖੋ, ਅਤੇ ਸਿਰਫ਼ ਉੱਪਰ ਦੀ ਆਵਾਜਾਈ ਘਟਾਉਣ ਲਈ ਕਦੇ ਵੀ ਜਨਤਕ ਤਾਜ਼ਗੀ ਨਿਯਮ ਨਾ ਜੋੜੋ।
ਹਿੱਸਾ, ਉਸਦੀ ਪੈਦਾ ਕੀਤੀ ਸਥਿਤੀ ਅਤੇ ਮੂਲ ਵੱਲੋਂ ਦੇਖਿਆ ਸਰੋਤ ਪਤਾ ਦੱਸਣ ਵਾਲੇ ਲਿਖਤੀ ਫੈਸਲੇ ਨਾਲ ਅੰਤ ਕਰੋ। ਸਹੀ ਬੇਨਤੀ, ਲਾਗੂ ਪ੍ਰਾਕਸੀ ਸੈਟਿੰਗਾਂ ਅਤੇ ਸਮਾਂ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਅਗਲੀ ਰਿਪੋਰਟ ਨੂੰ ਯਾਦਦਾਸ਼ਤ ਤੋਂ ਮੁੜ ਕੱਢਣ ਦੀ ਬਜਾਏ ਉਹਨਾਂ ਹੀ ਸਬੂਤਾਂ ਨਾਲ ਮਿਲਾਇਆ ਜਾ ਸਕੇ। ਉਹ ਰਿਕਾਰਡ ਅਗਲੀ ਰਿਪੋਰਟ ਦਾ ਜਵਾਬ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਸੇ 403 ਨੂੰ ਦੁਬਾਰਾ VPN ਰੁਕਾਵਟ ਵਜੋਂ ਨਿਦਾਨ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।