ਕੇਵਲ ਵੈੱਬ ਨੈੱਟਵਰਕ 'ਤੇ VPN ਬਲੌਕ? ਪਰਤਾਂ 'ਤੇ ਕੰਮ ਕਰੋ

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

ਸਾਬਤ ਕਰੋ ਕਿ ਕਿਹੜੀ ਪਰਤ ਕਨੈਕਸ਼ਨ ਨਾਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ

VPN ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਉਸੇ ਹੋਸਟ ਨੂੰ ਸਾਦੀ HTTPS ਬੇਨਤੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਮੇਂ ਦੇ ਪੜਾਅ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਜਿਹੜਾ ਪੜਾਅ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਉਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਯੰਤਰ ਜ਼ਿੰਮੇਵਾਰ ਹੈ:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

ਪ੍ਰੌਕਸੀ ਬਾਰੇ ਜਾਣੂ ਕਲਾਇੰਟ ਪਹਿਲਾ ਪੈਕੇਟ ਬਦਲਦਾ ਹੈ, ਨੀਤੀ ਨਹੀਂ

ਜੇ ਨੈੱਟਵਰਕ ਪ੍ਰਮਾਣਿਤ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ CONNECT ਮੰਗਦਾ ਹੈ, ਤਾਂ VPN ਕਲਾਇੰਟ ਨੂੰ ਦੱਸਣਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਉਹ ਉਸ ਪਤੇ 'ਤੇ ਸਾਕਟ ਖੋਲ੍ਹਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ ਜਿਸ ਨੂੰ ਉਹ ਰੂਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਪ੍ਰੌਕਸੀ ਨੂੰ ਕਲਾਇੰਟ ਤੋਂ ਵੱਖਰੀ ਪਰਖੋ, ਤਾਂ ਜੋ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਇੱਕੋ ਵਿਆਖਿਆ ਹੋਵੇ:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

ਪਹਿਲਾ ਹੁਕਮ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਪ੍ਰੌਕਸੀ ਮੰਜ਼ਿਲ ਢੋਵੇਗੀ। ਦੂਜਾ ਕਲਾਇੰਟ ਨੂੰ 443 'ਤੇ TCP ਵਰਤਣ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਇਹੀ ਇੱਕੋ ਢੋਆ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸਿਰਫ਼-ਵੈੱਬ ਰਾਹ ਅੱਗੇ ਭੇਜਦੇ ਹਨ। ਪਹਿਲਾ ਸਫਲ ਹੋਵੇ ਅਤੇ ਦੂਜਾ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਰੁਕਾਵਟ ਨਹੀਂ।

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

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

ਪੋਰਟ 443 ਪਹੁੰਚਯੋਗ ਹੈ, ਮਨਜ਼ੂਰ ਨਹੀਂ

443 'ਤੇ ਟਨਲ ਨੂੰ TLS ਵਿੱਚ ਲਪੇਟਣਾ ਪਹੁੰਚਯੋਗਤਾ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਪੋਰਟ ਜਾਂਚਣ ਵਾਲਾ ਫਿਲਟਰ ਇਸਨੂੰ ਲੰਘਾ ਦੇਵੇਗਾ; ਹੈਂਡਸ਼ੇਕ ਦੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਲੈਣ ਵਾਲਾ ਫਿਲਟਰ ਨਹੀਂ ਲੰਘਾਏਗਾ, ਅਤੇ ਐਨਕ੍ਰਿਪਟਡ ਕਲਾਇੰਟ ਹੈਲੋ ਸਰਵਰ ਦਾ ਨਾਮ ਸਿਰਫ਼ ਤਾਂ ਲੁਕਾਉਂਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਸਿਰੇ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਪਰਖ ਚਲਾਓ ਅਤੇ ਆਸ ਰੱਖਣ ਦੀ ਥਾਂ ਜਾਣੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਕਿਸਮ ਦੇ ਫਿਲਟਰ ਪਿੱਛੇ ਹੋ।

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

UDP ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾ ਸ਼ਿਕਾਰ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ TCP 443 ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ WireGuard ਜਾਂ ਡਿਫਾਲਟ OpenVPN ਕਦੇ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਨੈੱਟਵਰਕ UDP ਸੁੱਟ ਰਿਹਾ ਹੈ, ਅਤੇ ਕੁੰਜੀ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲੇਗਾ:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

ਕੱਲ੍ਹ ਕੰਮ ਕਰਦੇ ਪੀਅਰ ਦੇ ਕੋਲ ਖਾਲੀ ਹੈਂਡਸ਼ੇਕ ਸਮਾਂ-ਮੋਹਰ UDP ਦਾ ਜਵਾਬ ਹੈ। ਦੋ DNS ਪ੍ਰਸ਼ਨ ਕਿਸੇ ਹੋਰ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਜੇ ਸਥਾਨਕ ਰਿਜ਼ੋਲਵਰ ਅਤੇ ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਐਂਡਪੌਇੰਟ ਪਤੇ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਟੀਅਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ ਢੋਆ ਦੀ ਦਲੀਲ ਗਲਤ ਹੈ।

ਮਸ਼ੀਨ ਤੋਂ ਸੱਚਮੁੱਚ ਕੀ ਗਿਆ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

ਜੇ SYN ਪੈਕੇਟ ਦਿਸਦੇ ਹਨ ਅਤੇ SYN-ACK ਨਹੀਂ, ਤਾਂ ਰੋਕ ਉੱਪਰ ਵੱਲ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਨਿਰਦੋਸ਼ ਹੈ। ਜੇ ਸਰਵਰ ਦਾ ਨਾ ਹੋਣ ਵਾਲੇ ਪਤੇ 'ਤੇ ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਦਿਸਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰੌਕਸੀ ਜਾਂ ਰੋਕਣ ਵਾਲੇ ਨਾਲ ਗੱਲ ਕਰ ਰਹੇ ਹੋ। ਜੇ ਕੁਝ ਵੀ ਨਹੀਂ ਦਿਸਦਾ, ਤਾਂ ਕੋਈ ਨਤੀਜਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਸਹੀ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਕੈਪਚਰ ਕੀਤਾ।

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

ਵਾਪਸੀ, ਅਤੇ ਉਹ ਨੋਟ ਜੋ ਰੱਖਣ ਯੋਗ ਹੈ

ਤਬਦੀਲੀਆਂ ਨੂੰ ਉਸੇ ਉਲਟੇ ਕ੍ਰਮ ਵਿੱਚ ਹਟਾਓ ਜਿਸ ਵਿੱਚ ਕੀਤੀਆਂ ਸਨ। ਪ੍ਰੌਕਸੀ ਚਲ ਹਟਾਓ, ਹੱਥ ਨਾਲ ਸ਼ੁਰੂ ਕੀਤਾ ਕਲਾਇੰਟ ਬੰਦ ਕਰੋ, ਅਤੇ ਜੋੜਿਆ ਕੋਈ ਵੀ ਰੂਟ ਜਾਂ ਰਿਜ਼ੋਲਵਰ ਓਵਰਰਾਈਡ ਹਟਾਓ:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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