ਹੋਟਲ ਦੇ ਵਾਈ-ਫਾਈ 'ਤੇ OpenVPN ਕਨੈਕਟ ਨਹੀਂ ਹੁੰਦਾ? TCP 443 ਅਜ਼ਮਾਓ
ਘਰ ਵਿੱਚ ਚੱਲਣ ਵਾਲਾ ਪ੍ਰੋਫ਼ਾਈਲ ਹੋਟਲ ਜਾਂ ਕੈਂਪਸ ਦੇ ਵਾਈ-ਫਾਈ 'ਤੇ ਅਟਕ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਸ ਦਾ ਟਰਾਂਸਪੋਰਟ ਗੁਆਚ ਗਿਆ ਹੈ। ਬਲਾਕ ਸਾਬਤ ਕਰੋ, ਲਿਸਨਰ ਨੂੰ TCP 443 'ਤੇ ਲੈ ਜਾਓ ਤੇ ਕੀਮਤ ਜਾਣੋ।
ਕਲਾਇੰਟ ਖੋਲ੍ਹੋ, ਕਨੈਕਟ ਦਬਾਓ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਸੰਵਾਦ ਦੀ ਥਾਂ ਸਥਿਤੀ ਲਾਈਨ ਪੜ੍ਹੋ। ਹੋਟਲ, ਕੈਂਪਸ ਜਾਂ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਅਦ ਕਨੈਕਟ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਸਰਵਰ ਦੀ ਉਡੀਕ ਵਿੱਚ ਹੈ 'ਤੇ ਅਟਕਣ ਵਾਲਾ ਪ੍ਰੋਫ਼ਾਈਲ ਆਮ ਤੌਰ 'ਤੇ ਰਾਹ ਵਿੱਚ ਕਿਤੇ ਆਪਣਾ ਟਰਾਂਸਪੋਰਟ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਆਪਣੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਹੀਂ। ਅਗਲਾ ਲਾਭਦਾਇਕ ਕਦਮ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਸਰਵਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਨੈੱਟਵਰਕ ਕੀ ਢੋਂਦਾ ਹੈ। ਜਦੋਂ ਤੱਕ ਉਹੀ ਪ੍ਰੋਫ਼ਾਈਲ ਕਿਤੇ ਹੋਰ ਨਹੀਂ ਚੱਲਦਾ, ਕੁਝ ਨਾ ਬਦਲੋ।
ਪਹਿਲਾਂ ਫ਼ੋਨ ਦੇ ਹਾਟਸਪਾਟ ਤੋਂ ਜਾਂਚੋ। ਜੇ ਉੱਥੇ ਟਨਲ ਉੱਠਦੀ ਹੈ, ਤਾਂ ਸਰਵਰ, ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਖਾਤਾ ਸਭ ਠੀਕ ਹਨ, ਅਤੇ ਬਚਿਆ ਇੱਕੋ ਇੱਕ ਬਦਲਵਾਂ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਦਾ ਨੈੱਟਵਰਕ ਹੈ।
ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਸਥਿਤੀ ਲਾਈਨ ਪੜ੍ਹੋ
ਸਥਿਤੀ ਲਾਈਨ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਪੜਾਅ ਫੇਲ੍ਹ ਹੋਇਆ। ਕਨੈਕਟ ਹੋ ਰਿਹਾ ਹੈ 'ਤੇ ਅਟਕਿਆ ਕਲਾਇੰਟ ਅਜੇ ਹੋਸਟ ਹੱਲ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਬਾਹਰੀ ਸਾਕਟ ਖੋਲ੍ਹ ਰਿਹਾ ਹੈ; ਸਰਵਰ ਦੀ ਉਡੀਕ ਤੱਕ ਪਹੁੰਚਿਆ ਕਲਾਇੰਟ ਰਾਹ ਰੱਖਦਾ ਹੈ ਪਰ ਜਵਾਬ ਨਹੀਂ; ਜੋ ਪ੍ਰਮਾਣਿਤ ਹੋ ਕੇ ਫਿਰ ਡਿੱਗਦਾ ਹੈ ਉਸ ਦੀ ਸਮੱਸਿਆ ਬਿਲਕੁਲ ਵੱਖਰੀ ਹੈ। ਕਲਾਇੰਟ ਲਾਗ ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਦੇ ਆਪਣੇ remote ਤੇ proto ਖੇਤਰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕਲਾਇੰਟ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਮਾਂਡ-ਲਾਈਨ ਕਲਾਇੰਟ 'ਤੇ --verb 4 ਉਹੀ ਵੇਰਵਾ ਛਾਪਦਾ ਹੈ। ਉਸ ਦੀ ਤੁਲਨਾ ਸਾਹਮਣੇ ਦੇ ਨੈੱਟਵਰਕ ਨਾਲ ਕਰਨਾ ਹੀ 'ਵੀਪੀਐਨ ਬਲਾਕ ਹੈ' ਨੂੰ ਠੋਸ ਦਾਅਵੇ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਫਿਰ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਸੰਦਾਂ ਨਾਲ ਨੈੱਟਵਰਕ ਜਾਂਚੋ। nc -vzu 203.0.113.10 1194 ਇੱਕ UDP ਡੇਟਾਗ੍ਰਾਮ ਭੇਜਦਾ ਹੈ, curl -v telnet://203.0.113.10:443 ਦੱਸਦਾ ਹੈ ਕਿ TCP ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ HTTPS ਪੰਨਾ ਲੋਡ ਕਰਨ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬਾਹਰ ਜਾਣ ਵਾਲਾ 443 ਉਸ ਇੱਕੋ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਛੋਟੀਆਂ ਜਾਂਚਾਂ ਉਹ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਵੀਪੀਐਨ ਕਲਾਇੰਟ ਨਹੀਂ ਦੇ ਸਕਦਾ: ਇਸ ਨੈੱਟਵਰਕ ਤੋਂ ਕਿਹੜਾ ਪੋਰਟ ਤੇ ਕਿਹੜਾ ਪ੍ਰੋਟੋਕਾਲ ਬਾਹਰ ਜਾਂਦਾ ਹੈ।
ਤਿੰਨ ਨੈੱਟਵਰਕ ਵਿਵਹਾਰ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਤੇ ਵੱਖਰੇ ਜਵਾਬ ਮੰਗਦੇ ਹਨ। ਬਾਹਰ ਜਾਣ ਵਾਲਾ 443 ਖੁੱਲ੍ਹਾ ਹੋ ਸਕਦਾ ਹੈ, ਸਿਰਫ਼ ਪ੍ਰੌਕਸੀ ਦੀ ਆਗਿਆ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ 443 ਪਾਰਦਰਸ਼ੀ ਤੌਰ 'ਤੇ ਅਜਿਹੇ ਜਾਂਚ ਡੱਬੇ ਵੱਲ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ ਕਿ ਉਹ ਕੀ ਢੋਂਦਾ ਹੈ। ਪਹਿਲਾ ਹੇਠਾਂ ਦਿੱਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਬਦਲਾਅ ਨਾਲ ਠੀਕ ਹੁੰਦਾ ਹੈ, ਦੂਜਾ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ ਨਾਲ, ਅਤੇ ਤੀਜਾ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰ ਕੇ ਫਿਰ ਅਟਕ ਸਕਦਾ ਹੈ ਜਦੋਂ ਜਾਂਚਕਰਤਾ ਨੂੰ ਸਟ੍ਰੀਮ ਪਸੰਦ ਨਾ ਆਵੇ। ਇਹ ਜਾਣਨਾ ਕਿ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਹੈ, ਦਸ ਮਿੰਟ ਦੇ ਬਦਲਾਅ ਤੇ ਅੱਧਾ ਦਿਨ ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਨ ਦਾ ਫ਼ਰਕ ਹੈ।
ਲਿਸਨਰ ਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਇਕੱਠੇ ਲੈ ਜਾਓ
ਸਰਵਰ ਵੱਲ, ਲਿਸਨਰ ਨੂੰ ਉਸ 'ਤੇ ਰੱਖੋ ਜਿਸ ਦੀ ਨੈੱਟਵਰਕ ਆਗਿਆ ਦਿੰਦਾ ਹੈ: ਸਰਵਰ ਕੌਨਫ਼ਿਗਰੇਸ਼ਨ ਵਿੱਚ port 443 ਤੇ proto tcp, ਫਿਰ ਸੇਵਾ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ ਤੇ ss -lntp ਨਾਲ ਸਾਕਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਕਲਾਇੰਟ ਵੱਲ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਸਹਿਮਤ ਹੋਣਾ ਪਵੇਗਾ, ਕਿਉਂਕਿ ਟਰਾਂਸਪੋਰਟ ਤੇ ਪੋਰਟ ਟਨਲ ਤੋਂ ਬਾਹਰ ਹਨ: .ovpn ਵਿੱਚ proto tcp ਤੇ port 443, ਜਾਂ ਐਪ ਦੀ ਸੈਟਿੰਗ ਸਕਰੀਨ ਵਿੱਚ ਸੰਬੰਧਿਤ ਖੇਤਰ। ਅਜੇ ਵੀ UDP 1194 ਵੱਲ ਨਿਸ਼ਾਨਾ ਪ੍ਰੋਫ਼ਾਈਲ ਬਿਲਕੁਲ ਪਹਿਲਾਂ ਵਾਂਗ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤੇ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕੀਤੇ ਫਾਇਰਵਾਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਦਾ ਮਨ ਕਰਦਾ ਹੈ। ਜੇ ਉਹੀ ਹੋਸਟ 443 'ਤੇ HTTPS ਦਾ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਦੋਵੇਂ ਲਿਸਨਰ ਉਹ ਪਤਾ ਤੇ ਪ੍ਰੋਟੋਕਾਲ ਸਾਂਝਾ ਨਹੀਂ ਕਰ ਸਕਦੇ; ਵੀਪੀਐਨ ਨੂੰ ਦੂਜਾ ਪਤਾ ਦਿਓ ਜਾਂ ਅੱਗੇ ਡੀਮਲਟੀਪਲੈਕਸਰ ਰੱਖੋ।
ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ tcpdump -ni any port 443 ਨਾਲ ਪਹਿਲਾ ਕਨੈਕਸ਼ਨ ਵੇਖੋ। ਕਲਾਇੰਟ ਤੋਂ ਨਿਕਲ ਕੇ ਕਦੇ ਨਾ ਪਹੁੰਚਣ ਵਾਲੇ ਪੈਕਟ ਦਾ ਅਰਥ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਫਿਰ ਵੀ ਫਿਲਟਰ ਕਰ ਰਿਹਾ ਹੈ, ਜਾਂ ਪ੍ਰੋਫ਼ਾਈਲ ਦਾ ਪਤਾ ਉਹ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਮੰਨ ਰਹੇ ਹੋ। ਜਵਾਬ ਤੋਂ ਬਿਨਾਂ ਪਹੁੰਚਣ ਵਾਲੇ ਪੈਕਟ ਤੁਹਾਨੂੰ ਸਰਵਰ ਲਾਗ ਵੱਲ ਵਾਪਸ ਭੇਜਦੇ ਹਨ, ਜਿੱਥੇ ਪ੍ਰੋਟੋਕਾਲ ਦੀ ਅਸੰਗਤ ਤੁਰੰਤ ਸੁੱਟੇ ਪੈਕਟ ਵਜੋਂ ਦਿਸਦੀ ਹੈ।
ਜਦੋਂ ਨੈੱਟਵਰਕ ਤੋਂ ਸਿਰਫ਼ ਪ੍ਰੌਕਸੀ ਬਾਹਰ ਜਾਂਦੀ ਹੈ
ਕੁਝ ਮਹਿਮਾਨ ਨੈੱਟਵਰਕ HTTP ਪ੍ਰੌਕਸੀ ਤੋਂ ਬਿਨਾਂ ਕੁਝ ਨਹੀਂ ਦਿੰਦੇ, ਇਹ ਬੰਦ ਪੋਰਟ ਤੋਂ ਵੱਖਰੀ ਰੁਕਾਵਟ ਹੈ ਤੇ OpenVPN ਤੋਂ ਵੱਧ ਨੂੰ ਬਾਹਰ ਰੱਖਦੀ ਹੈ। ਸਿਰਫ਼ PPTP, L2TP/IPsec ਜਾਂ ਨੰਗੇ IPsec ਬੋਲਣ ਵਾਲੇ ਕਲਾਇੰਟ ਲਈ ਉਸ ਵਿੱਚੋਂ ਨਿਕਲਣ ਦਾ ਕੋਈ ਰਾਹ ਨਹੀਂ, ਕਿਉਂਕਿ ਉਹ ਡਿਜ਼ਾਈਨ ਮੰਨਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਦਾ ਬਾਹਰੀ ਪ੍ਰੋਟੋਕਾਲ ਸਿੱਧਾ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚੇਗਾ। OpenVPN ਕਰ ਸਕਦਾ ਹੈ, ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ http-proxy proxy.example.net 8080 ਨਾਲ, ਬਸ਼ਰਤੇ ਪ੍ਰੌਕਸੀ ਤੁਹਾਡੇ ਪੋਰਟ ਤੱਕ CONNECT ਢੰਗ ਦੀ ਆਗਿਆ ਦੇਵੇ। SOCKS ਪ੍ਰੌਕਸੀ ਹੋਰ ਵੀ ਸੌਖੀ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਅੰਦਰ ਕੀ ਹੈ ਇਸ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਸਟ੍ਰੀਮ ਅੱਗੇ ਭੇਜਦੀ ਹੈ।
ਜਿੱਥੇ ਕਲਾਇੰਟ ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਸਹਾਇਤਾ ਨਹੀਂ, ਉੱਥੇ 443 'ਤੇ SSH ਟਨਲ ਆਮ ਤੌਰ 'ਤੇ ਬਚਦੀ ਹੈ। ਇਹ ਦੂਜੀ ਪਰਤ ਜੋੜਦੀ ਹੈ, ਤੇ ਨੈੱਟਵਰਕ ਦਾ ਸੰਚਾਲਕ ਇਸ ਬਾਰੇ ਰਾਏ ਰੱਖ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਇੱਕ ਯਾਤਰਾ ਦਾ ਪੁਲ ਸਮਝੋ, ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ।
ਰੱਖਣ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਵੇਂ ਰਾਹ ਦੀ ਕੀਮਤ ਜਾਣੋ
TCP ਦੇ ਅੰਦਰ TCP ਦੀ ਜਾਣੀ-ਪਛਾਣੀ ਕੀਮਤ ਹੈ। ਜਦੋਂ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ TCP ਹੁੰਦਾ ਹੈ ਤੇ ਪੇਲੋਡ ਵੀ TCP, ਤਾਂ ਗੁਆਚਿਆ ਸੈਗਮੈਂਟ ਦੋਵੇਂ ਪਰਤਾਂ 'ਤੇ ਮੁੜ-ਭੇਜਣਾ ਭੜਕਾਉਂਦਾ ਹੈ, ਤੇ ਅੰਦਰਲਾ ਕਨੈਕਸ਼ਨ ਅਜਿਹੇ ਨੁਕਸਾਨ ਤੋਂ ਪਿੱਛੇ ਹਟਦਾ ਹੈ ਜੋ ਉਸ ਨੂੰ ਦਿਸਦਾ ਨਹੀਂ। ਬ੍ਰਾਊਜ਼ਿੰਗ ਇਹ ਸਹਿ ਜਾਂਦੀ ਹੈ; ਇੰਟਰੈਕਟਿਵ ਸੈਸ਼ਨ ਤੇ ਕਾਲਾਂ ਇਹ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। TCP 443 ਲਿਸਨਰ ਨੂੰ ਉਹਨਾਂ ਨੈੱਟਵਰਕਾਂ ਲਈ ਬਦਲਵਾਂ ਰਾਹ ਰੱਖੋ ਜੋ ਇਸ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਤੇ UDP ਨੂੰ ਉਹਨਾਂ ਸਭ ਲਈ ਡਿਫ਼ਾਲਟ ਰਹਿਣ ਦਿਓ ਜੋ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਜਾਣ ਦਿੰਦੇ ਹਨ।
ਚੋਣ ਪ੍ਰੋਫ਼ਾਈਲ ਦੇ ਨਾਮ ਵਿੱਚ ਤੇ ਸਹਾਇਤਾ ਨੋਟਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ: ਕਿਹੜਾ ਪੋਰਟ, ਕਿਹੜਾ ਪ੍ਰੋਟੋਕਾਲ ਤੇ ਕਿਹੜੇ ਨੈੱਟਵਰਕ ਨੇ ਇਸ ਨੂੰ ਭੜਕਾਇਆ। ਫਿਰ ਨੈੱਟਵਰਕ ਦੇ ਪ੍ਰਬੰਧਕ ਨੂੰ ਪੁੱਛੋ ਕਿ ਅਗਲੀ ਉਪਕਰਣ ਬਦਲੀ ਤੋਂ ਬਾਅਦ ਵੀ ਉਹ ਪੋਰਟ ਖੁੱਲ੍ਹਾ ਰਹੇਗਾ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਚੁੱਪਚਾਪ ਗਾਇਬ ਹੋਣ ਵਾਲਾ ਬਦਲਵਾਂ ਰਾਹ ਕੋਈ ਵੀ ਬਦਲ ਨਾ ਹੋਣ ਨਾਲੋਂ ਮਾੜਾ ਹੈ।