UDP ਹਮੇਸ਼ਾ ਤੇਜ਼ ਨਹੀਂ ਹੁੰਦਾ: OpenVPN ਟਰਾਂਸਪੋਰਟ ਚੁਣਨਾ
UDP OpenVPN ਲਈ ਇੱਕ ਸਮਝਦਾਰ ਡਿਫ਼ਾਲਟ ਹੈ, ਫ਼ੈਸਲਾ ਨਹੀਂ। ਇੱਕੋ ਰਸਤੇ ਅਤੇ ਕੰਮ 'ਤੇ ਟਰਾਂਸਪੋਰਟ ਦੀ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਜਾਂਚੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰੋਤਾ ਚੱਲ ਰਿਹਾ ਹੈ।
ਹਰ ਗਾਈਡ ਕਹਿੰਦੀ ਹੈ ਕਿ OpenVPN ਲਈ UDP, TCP ਨਾਲੋਂ ਵਧੀਆ ਹੈ, ਅਤੇ ਇਹ ਸਲਾਹ ਡਿਫ਼ਾਲਟ ਹੈ, ਮਾਪ ਨਹੀਂ। ਟਰਾਂਸਪੋਰਟ ਬਦਲਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿਵੇਂ ਪਹੁੰਚਾਏ ਜਾਂਦੇ ਹਨ ਅਤੇ ਜਦੋਂ ਰਸਤਾ ਉਨ੍ਹਾਂ ਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਟਨਲ ਕਿਵੇਂ ਐਨਕ੍ਰਿਪਟ ਹੁੰਦੀ ਹੈ। ਕੈਪਟਿਵ ਪੋਰਟਲ ਜਾਂ ਸਿਰਫ਼ ਪੋਰਟ 443 ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੇ ਪ੍ਰੌਕਸੀ ਪਿੱਛੇ, ਹੌਲੀ ਵਿਕਲਪ ਹੀ ਅਸਲ ਵਿੱਚ ਜੁੜਦਾ ਹੈ। ਅੱਗੇ ਇਹ ਵੱਖ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਪ੍ਰੋਟੋਕੋਲ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਐਕਸੈਸ ਨੈੱਟਵਰਕ ਕੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਟਰਾਂਸਪੋਰਟ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ
TCP ਭਰੋਸੇਯੋਗ, ਕ੍ਰਮਬੱਧ ਬਾਈਟ ਸਟ੍ਰੀਮ ਦਿੰਦਾ ਹੈ ਅਤੇ ਜੋ ਗੁਆਚਦਾ ਹੈ ਉਹ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ, ਜਿਵੇਂ RFC 9293 ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। UDP ਡੇਟਾਗ੍ਰਾਮ ਨੈੱਟਵਰਕ ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਅਤੇ OpenVPN ਉਸ ਸਾਕਟ ਉੱਤੇ ਆਪਣੀ ਭਰੋਸੇਯੋਗਤਾ ਪਰਤ ਚਲਾਉਂਦਾ ਹੈ। TCP ਨੂੰ TCP ਦੇ ਅੰਦਰ ਐਨਕੈਪਸੁਲੇਟ ਕਰਨ ਨਾਲ ਦੋ ਰਿਕਵਰੀ ਲੂਪ ਢੇਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਗੁਆਚਿਆ ਸੈਗਮੈਂਟ ਅੰਦਰਲੀ ਸਟ੍ਰੀਮ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ ਜਦ ਤੱਕ ਬਾਹਰੀ ਮੁੜ-ਭੇਜਣਾ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਇਹੀ ਆਪਸੀ ਕਿਰਿਆ UDP ਦੇ ਪੱਖ ਵਿੱਚ ਅਸਲ ਦਲੀਲ ਹੈ, ਅਤੇ ਇਹ ਥ੍ਰੂਪੁਟ ਦੀ ਬਜਾਏ ਲੇਟੈਂਸੀ ਵਜੋਂ ਦਿਸਦੀ ਹੈ।
ਪ੍ਰਭਾਵ ਨੁਕਸਾਨ ਅਤੇ ਆਉਣ-ਜਾਣ ਦੇ ਸਮੇਂ ਨਾਲ ਵਧਦਾ ਹੈ। ਸਾਫ਼ ਸਥਾਨਕ ਰਸਤੇ 'ਤੇ ਦੋਵੇਂ ਟਰਾਂਸਪੋਰਟ ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਹਨ, ਇਸ ਲਈ ਲੈਬ ਟੈਸਟ ਸ਼ਿਕਾਇਤ ਨੂੰ ਘੱਟ ਹੀ ਦੁਹਰਾਉਂਦਾ ਹੈ। ਭੀੜ ਵਾਲੇ ਮੋਬਾਈਲ ਲਿੰਕ 'ਤੇ ਵੱਡੇ ਟ੍ਰਾਂਸਫ਼ਰ ਨੂੰ ਕੁਝ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਇੰਟਰੈਕਟਿਵ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਫ਼ਰਕ ਦਿਸਦਾ ਹੈ।
ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਗੋਪਨੀਯਤਾ ਜਾਂ ਅਖੰਡਤਾ ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ। TLS ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਡੇਟਾ-ਚੈਨਲ ਸਾਈਫ਼ਰ ਦੋਵੇਂ ਟਰਾਂਸਪੋਰਟਾਂ ਲਈ ਇੱਕੋ ਹਨ, ਇਸ ਲਈ ਬਦਲਣ ਨਾਲ ਕਮਜ਼ੋਰ ਸਾਈਫ਼ਰ ਸੂਟ ਨਹੀਂ ਬਚ ਸਕਦਾ।
TCP ਆਪਣੀ ਥਾਂ ਕਿੱਥੇ ਕਮਾਉਂਦਾ ਹੈ
ਐਕਸੈਸ ਨੈੱਟਵਰਕ TCP ਚੁਣਨ ਦਾ ਆਮ ਕਾਰਨ ਹਨ। ਹੋਟਲ, ਹਵਾਈ ਅੱਡਾ ਜਾਂ ਮਹਿਮਾਨ ਨੈੱਟਵਰਕ ਬਾਹਰ ਜਾਣ ਵਾਲੇ 443 ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਬਾਕੀ ਸਭ ਸੁੱਟ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਸ ਪੋਰਟ 'ਤੇ TCP ਸਰੋਤਾ ਹੀ ਇਕੱਲਾ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਫ਼ਾਈਲ ਹੈ। ਇਹ ਪਹੁੰਚ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਨਹੀਂ, ਅਤੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇਹ ਕਾਫ਼ੀ ਚੰਗਾ ਕਾਰਨ ਹੈ।
TCP ਤਦ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਰਸਤਾ ਸਥਿਰ ਹੋਵੇ ਪਰ ਵਿਚਕਾਰਲੇ ਬਾਕਸ ਦੁਸ਼ਮਣਾਨਾ ਹੋਣ। ਕੁਝ ਨੈੱਟਵਰਕ ਲੰਬੇ ਸਮੇਂ ਦੇ UDP ਪ੍ਰਵਾਹ ਨੂੰ ਰੀਸੈਟ ਕਰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਆਮ ਵੈੱਬ ਟ੍ਰੈਫ਼ਿਕ ਵਰਗੇ ਦਿਸਦੇ TCP ਸੈਸ਼ਨ ਸਹਿ ਲੈਂਦੇ ਹਨ। ਇਹ ਸਮਾਨਤਾ ਸਫਲ ਹੁੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਖ਼ਾਸ ਨੈੱਟਵਰਕ ਦਾ ਗੁਣ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਗਾਈਡ ਸਾਰਿਆਂ ਲਈ ਇਸ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਪਰਖੋ ਜੋ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।
ਰੱਦ ਕੀਤਾ ਲੌਗਇਨ ਟਰਾਂਸਪੋਰਟ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਕਨੈਕਸ਼ਨ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਲੰਘਾਉਣ ਲਈ ਸਰਟੀਫ਼ਿਕੇਟ ਪੁਸ਼ਟੀਕਰਨ ਬੰਦ ਕਰਨਾ ਇੱਕ ਹੋਰ ਬਦਲਾਅ ਹੈ, ਜਿਸਦਾ ਨਤੀਜਾ ਬਹੁਤ ਮਾੜਾ ਹੈ।
TCP ਪ੍ਰੋਫ਼ਾਈਲ ਤਿਆਰ ਰੱਖਣਾ ਵਿਹਾਰਕ ਸਮਝੌਤਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਕਲਾਇੰਟ ਦੋਵੇਂ ਸੰਭਾਲਦੇ ਹਨ ਅਤੇ ਨੈੱਟਵਰਕ ਵੱਲੋਂ UDP ਰਸਤਾ ਰੱਦ ਕਰਨ 'ਤੇ ਬਦਲਣ ਦਿੰਦੇ ਹਨ, ਜੋ ਲੋੜ ਪੈਣ ਤੱਕ ਕੁਝ ਖ਼ਰਚ ਨਹੀਂ ਕਰਦਾ। ਜੋ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਉਹ ਹੈ ਵੱਖ-ਵੱਖ ਐਂਡਪੁਆਇੰਟਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਦੋ ਪ੍ਰੋਫ਼ਾਈਲਾਂ ਭੇਜਣਾ, ਕਿਉਂਕਿ ਫਿਰ ਤੁਹਾਡੀ ਤੁਲਨਾ ਸਰਵਰਾਂ ਨੂੰ ਮਾਪਦੀ ਹੈ।
ਜਾਂਚੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰੋਤਾ ਹੈ
ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਤੁਲਨਾ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਦੋਵੇਂ ਸਿਰੇ ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਪੋਰਟ 'ਤੇ ਸਹਿਮਤ ਹਨ। ਕਲਾਇੰਟ ਫ਼ਾਈਲ ਵਿੱਚ proto udp ਨੂੰ proto tcp ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਸਰਵਰ ਸਰੋਤਾ ਨਹੀਂ ਬਣਦਾ। ਸਰਵਰ ਨੂੰ ਉਸ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਸੰਰਚਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਉਸ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ।
grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn
grep ਪ੍ਰਿੰਟ ਕਰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਨੂੰ ਕੀ ਵਰਤਣ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ, ਜਦੋਂ ਕਿ ਦੋ ਸਾਕਟ ਸੂਚੀਆਂ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਇਹ ਕਿਸ ਨਾਲ ਬੰਨ੍ਹਿਆ ਹੈ। UDP ਸਰੋਤਾ ਸਿਰਫ਼ ਪਹਿਲੀ ਸੂਚੀ ਵਿੱਚ ਅਤੇ TCP ਸਰੋਤਾ ਸਿਰਫ਼ ਦੂਜੀ ਵਿੱਚ ਦਿਸਦਾ ਹੈ, ਇਸ ਲਈ ਗੁੰਮ ਲਾਈਨ ਹੀ ਉਸ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਲੱਭਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਜੋ ਕਦੇ ਲਾਗੂ ਨਹੀਂ ਹੋਇਆ। ਪੋਰਟ ਦੀ ਵੀ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ 1194 'ਤੇ TCP ਪ੍ਰੋਫ਼ਾਈਲ ਜ਼ਿਆਦਾਤਰ ਐਕਸੈਸ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ 443 ਨਾਲੋਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਸੇਵਾ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਬਾਈਂਡਿੰਗ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਵਾਲੀ ਲੌਗ ਲਾਈਨ ਪੜ੍ਹੋ।
ਕਲਾਇੰਟ ਪਾਸੇ ਦੀ ਪੁਸ਼ਟੀ ਸਸਤੀ ਹੈ: --verb 4 ਨਾਲ ਕਨੈਕਸ਼ਨ ਚਲਾਓ ਅਤੇ ਲੌਗ ਵਿੱਚ ਟਰਾਂਸਪੋਰਟ ਲਾਈਨ ਪੜ੍ਹੋ। ਜੇ ਕਲਾਇੰਟ UDP ਕਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸਰਵਰ TCP 'ਤੇ ਸੁਣ ਰਿਹਾ ਹੈ, ਤਾਂ ਹੈਂਡਸ਼ੇਕ ਕਦੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਕੋਈ ਟਿਊਨਿੰਗ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ।
ਟਰਾਂਸਪੋਰਟ ਦਾ ਲੇਬਲ ਨਹੀਂ, ਕੰਮ ਦਾ ਭਾਰ ਤੁਲੋ
ਨਿਆਂਪੂਰਨ ਤੁਲਨਾ ਟਰਾਂਸਪੋਰਟ ਤੋਂ ਇਲਾਵਾ ਸਭ ਕੁਝ ਸਥਿਰ ਰੱਖਦੀ ਹੈ। ਉਹੀ ਡਿਵਾਈਸ, ਉਹੀ ਐਕਸੈਸ ਨੈੱਟਵਰਕ, ਉਹੀ ਮੰਜ਼ਿਲ ਹੋਸਟ, ਉਹੀ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਉਹੀ ਸਰਵਰ। ਜੇ ਦੋਵੇਂ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਖ-ਵੱਖ ਹੋਸਟਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਹੋਸਟਾਂ ਨੂੰ ਵੀ ਮਾਪ ਰਹੇ ਹੋ।
ਹਰ ਰਨ ਲਈ ਤਿੰਨ ਨਤੀਜੇ ਦਰਜ ਕਰੋ: ਟਨਲ ਬਣਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਟਿਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕੰਮ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਚੱਲਣ ਅਤੇ ਵੱਡੇ ਟ੍ਰਾਂਸਫ਼ਰ ਅਟਕਣ ਤਾਂ ਇਹ ਟਰਾਂਸਪੋਰਟ ਨਹੀਂ, ਪੈਕਟ ਆਕਾਰ ਅਤੇ MTU ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਵਾਰ-ਵਾਰ ਮੁੜ-ਕਨੈਕਟ ਰਸਤੇ ਜਾਂ ਵਿਚਕਾਰਲੇ ਬਾਕਸ ਦੇ ਸਮਾਂ-ਸਮਾਪਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ।
ਜੋ ਪ੍ਰੋਫ਼ਾਈਲ ਤੁਹਾਡੀਆਂ ਅਸਲ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ ਉਹ ਰੱਖੋ, ਅਤੇ ਦੂਜੀ ਸੰਭਾਲੋ। ਚੋਣ ਵਿਅਕਤੀ ਦੀ ਨਹੀਂ, ਨੈੱਟਵਰਕ ਦੀ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਇੱਕਲਾ ਡਿਫ਼ਾਲਟ ਜਵਾਬ ਕਿਤੇ ਨਾ ਕਿਤੇ ਗ਼ਲਤ ਹੈ।