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

ਚਾਰ ਪੜਾਅ, ਚਾਰ ਵੱਖਰੀਆਂ ਅਸਫਲਤਾਵਾਂ

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

StageLooks likeWhat it does not prove
Name resolutionfails in under a second, before any contactnothing about the server being up
Transportwaits the full timeout, then gives upnothing about the VPN service behind the port
Negotiationconnects, then stalls at handshakenothing about credentials
Logina reply arrives and is rejected or hangs on a promptnothing about reachability

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

ਕਿਸੇ ਵੀ ਸੰਪਰਕ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਹੱਲ ਹੋਣਾ ਫੇਲ ਹੁੰਦਾ ਹੈ

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

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

ਆਵਾਜਾਈ ਸੈੱਟਅੱਪ ਨਾ ਆਉਣ ਵਾਲੇ ਪੈਕੇਟ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ

ਜਦੋਂ DNS ਠੀਕ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਫਿਰ ਵੀ ਪੂਰੀ ਸਮਾਂ-ਸੀਮਾ ਸਾੜ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਆਵਾਜਾਈ ਪਰਤ ਸ਼ੱਕੀ ਹੈ। TCP 'ਤੇ ਤੁਸੀਂ ਪੋਰਟ ਸਿੱਧਾ ਜਾਂਚ ਸਕਦੇ ਹੋ; Test-NetConnection Windows 'ਤੇ ਜਾਂ nc -vz Linux 'ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਕੋਈ ਚੀਜ਼ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਹ ping ਨਾਲੋਂ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਹੈ। UDP 'ਤੇ ਤੁਸੀਂ ਇਸੇ ਤਰ੍ਹਾਂ ਜਾਂਚ ਨਹੀਂ ਸਕਦੇ, ਕਿਉਂਕਿ ਉਸ ਪਰਤ 'ਤੇ ਪੂਰਾ ਕਰਨ ਲਈ ਕੋਈ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ, ਅਤੇ ਇਹ ਅਸਮਾਨਤਾ ਬਹੁਤ ਸਾਰੇ ਗਲਤ ਸਿੱਟੇ ਪੈਦਾ ਕਰਦੀ ਹੈ।

TCP ਜਾਂਚ ਜੋ ਸਾਬਤ ਕਰਦੀ ਹੈ ਉਹ ਸੀਮਿਤ ਹੈ: 443 ਪੋਰਟ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ VPN ਸਰੋਤਾ ਹੋਵੇ, ਅਤੇ ਸਿਰਫ਼-UDP ਐਂਡਪੌਇੰਟ ਕੋਲ ਕੁਝ ਵੀ ਸਵੀਕਾਰ ਕਰਨ ਲਈ TCP ਪੋਰਟ ਨਹੀਂ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਨੂੰ UDP ਤੋਂ TCP ਵਿੱਚ ਮੁੜ ਲਿਖਣ ਨਾਲ ਦੂਜੇ ਪਾਸੇ ਸਰੋਤਾ ਨਹੀਂ ਬਣਦਾ; ਇਹ ਸਿਰਫ਼ ਬਦਲਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਕਿਸ ਲਈ ਉਡੀਕਦਾ ਹੈ। ਜੇ ਨੈੱਟਵਰਕ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਬਦਲਾਅ ਉਸੇ ਪੜਾਅ 'ਤੇ ਵੱਖਰਾ ਟਾਈਮਆਊਟ ਪੈਦਾ ਕਰਦਾ ਹੈ।

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

ਗੱਲਬਾਤ ਅਤੇ ਲੌਗਇਨ ਦਾ ਅਰਥ ਹੈ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ

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

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

ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਬੂਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ