ਇੱਕੋ ਰਾਊਟਰ ਪਿੱਛੇ ਸਿਰਫ਼ ਇੱਕ VPN ਕਲਾਇੰਟ ਕਿਉਂ ਜੁੜਦਾ ਹੈ

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

ਕਲਾਇੰਟ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਗੇਟਵੇ ਦਾ ਲੌਗ ਪੜ੍ਹੋ

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

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

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

ਰਾਊਟਰ GRE ਅਤੇ NAT-T ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ

PPTP ਆਮ ਦੋਸ਼ੀ ਹੈ: ਕੰਟਰੋਲ ਚੈਨਲ TCP 1723 ਹੈ ਜਦੋਂ ਕਿ ਡੇਟਾ ਰਾਹ GRE, ਭਾਵ IP ਪ੍ਰੋਟੋਕੋਲ 47 ਹੈ। ਬਹੁਤ ਸਾਰੇ ਖਪਤਕਾਰ ਰਾਊਟਰ ਇੱਕੋ ਕੰਟਰੋਲ ਕਨੈਕਸ਼ਨ ਟਰੈਕ ਕਰਨ ਵਾਲੇ PPTP ਸਹਾਇਕ ਨਾਲ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਸੇ NAT ਪਿੱਛੇ ਦੂਜਾ ਕਲਾਇੰਟ ਆਪਣਾ ਕੰਟਰੋਲ ਚੈਨਲ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਫਿਰ ਡੇਟਾ ਰਾਹ ਬਿਲਕੁਲ ਨਹੀਂ ਮਿਲਦਾ। 47 ਨੰਬਰ ਦਾ TCP ਪੋਰਟ ਫਾਰਵਰਡ ਕਰਨ ਨਾਲ GRE ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ GRE ਪੋਰਟ ਨਹੀਂ, ਪ੍ਰੋਟੋਕੋਲ ਨੰਬਰ ਹੈ।

L2TP IPsec ਉੱਤੇ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ: IKE UDP 500 ਵਰਤਦਾ ਹੈ, NAT ਟ੍ਰੈਵਰਸਲ ਸੁਰੱਖਿਅਤ ਪੇਲੋਡ ਨੂੰ UDP 4500 ਉੱਤੇ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਠੀਕ ਇਸ ਲਈ ਹੈ ਕਿ ਇੱਕ ਪਤੇ ਪਿੱਛੇ ਕਈ ਕਲਾਇੰਟ ਉਸੇ ਗੇਟਵੇ ਤੱਕ ਪੁੱਜ ਸਕਣ। ਇਹ ਡਿਜ਼ਾਈਨ ਗੇਟਵੇ ਜਾਂ ਵਿਚਕਾਰਲੇ ਡੱਬੇ ਨੂੰ ਹਰ ਪਤੇ ਲਈ ਸੈਸ਼ਨ ਸੀਮਾ ਲਾਉਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ, ਅਤੇ ਸੋਫ਼ੇ ਤੋਂ ਦੋਵੇਂ ਅਸਫ਼ਲਤਾਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ। SoftEther ਦੇ ਆਪਣੇ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਵੀ ਇਸੇ ਸ਼੍ਰੇਣੀ ਦੀ ਸਮੱਸਿਆ ਹੈ: ਕੰਮ ਕਰਨ ਵਾਲੇ ਪਾਸ-ਥਰੂ ਤੋਂ ਬਿਨਾਂ ਰਾਊਟਰ LAN ਤੋਂ ਪਹਿਲੇ ਕਲਾਇੰਟ ਨੂੰ ਅੰਦਰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਰਾਊਟਰ ਦਾ ALG ਜਾਂ ਪਾਸ-ਥਰੂ ਸਵਿੱਚ ਦੋਵੇਂ ਹਾਲਤਾਂ ਵਿੱਚ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਲਈ ਲਿਖਿਆ ਸਹਾਇਕ ਅੱਜ ਦੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਭੇਜੇ ਪੈਕਟ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ।

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

ਢੋਆ-ਢੁਆਈ ਸੀਮਾ ਵਰਗੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਪਛਾਣ ਸੀਮਾਵਾਂ

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

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

ਮੁਰੰਮਤ ਨੂੰ ਲੌਗ ਐਂਟਰੀ ਨਾਲ ਮਿਲਾਓ

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

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

ਦੋ ਜੀਵਤ ਸੈਸ਼ਨਾਂ ਦੀ ਪੁਸ਼ਟੀ

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

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