ਕੀ TCP 443 ਸੱਚਮੁੱਚ ਮਦਦ ਕਰਦਾ ਹੈ? ਸਿਰਫ਼ ਜਦੋਂ ਸਰਵਰ ਉੱਥੇ ਸੁਣਦਾ ਹੋਵੇ
TCP ਪਰੋਫਾਈਲ ਇੱਕ ਬਦਲਵਾਂ ਰਾਹ ਹੈ, ਭੇਸ ਨਹੀਂ। ਜਾਂਚੋ ਕਿ ਸਰਵਰ ਉਸ ਪੋਰਟ 'ਤੇ ਸੁਣਦਾ ਹੈ, ਫਿਰ ਦੋਹਰੇ TCP ਦੀ ਕੀਮਤ ਨੂੰ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋਣ ਦੇ ਸਾਹਮਣੇ ਤੋਲੋ।
TCP 443 ਇੱਕ ਪੂਰਵ-ਸ਼ਰਤ ਵਾਲਾ ਬਦਲਵਾਂ ਰਾਹ ਹੈ, ਕਿਸੇ ਵੀ ਫਿਲਟਰ ਵਿੱਚੋਂ ਸੁਰੰਗ ਲੰਘਾਉਣ ਵਾਲਾ ਭੇਸ ਨਹੀਂ। ਇਹ ਤਦ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਓਪਰੇਟਰ ਪਹਿਲਾਂ ਹੀ ਉਸ ਪੋਰਟ 'ਤੇ TCP ਸਰੋਤਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਰਾਹ ਘੰਟਿਆਂ ਤੱਕ ਖੁੱਲ੍ਹੀ ਰਹਿਣ ਵਾਲੀ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਹਿੰਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਨਾ ਹੋਵੇ ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਮਾਂ-ਸਮਾਪਤੀ ਵਜੋਂ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਮਾਂ-ਸਮਾਪਤੀ ਘੱਟ ਹੀ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ। ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਤਿੰਨ ਸਵਾਲ ਮੰਗਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਪੋਰਟ ਨੰਬਰ ਬਾਰੇ ਹੈ।
ਪੋਰਟ ਨੰਬਰ ਢੋਆ-ਢੁਆਈ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਹੈ
ਪੋਰਟ ਇੱਕ ਸਿਰੇ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ; TCP ਇਸਨੂੰ ਤਰਤੀਬਵਾਰ ਬਾਈਟ ਵਹਾਅ ਬਣਾ ਦਿੰਦਾ ਹੈ; OpenVPN ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਵਹਾਅ ਅੰਦਰ ਕੀ ਚੱਲਦਾ ਹੈ। ਉਸੇ ਨੰਬਰ 'ਤੇ ਵੈੱਬ ਸਰਵਰ ਬਿਲਕੁਲ ਵੱਖਰੀ ਐਪਲੀਕੇਸ਼ਨ ਸੰਰਚਨਾ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ 443 ਪੋਰਟ ਸਾਂਝਾ ਕਰਨਾ ਦੋਵਾਂ ਨੂੰ ਫਿਲਟਰ ਲਈ ਇੱਕੋ ਜਿਹਾ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ। ਨੰਬਰ ਇੱਕ ਸੰਕੇਤ ਹੈ ਜੋ ਫਿਲਟਰ ਪੜ੍ਹਦਾ ਹੈ, ਪੈਕਟਾਂ ਦੀ ਸਮੱਗਰੀ ਬਦਲਣ ਵਾਲਾ ਗੁਣ ਨਹੀਂ। ਸਿਰਫ਼ ਪੋਰਟ ਸਾਂਝਾ ਕਰਨ ਕਰਕੇ ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਮੰਨਣਾ ਇੱਥੋਂ ਦੀ ਬਹੁਤੀ ਉਲਝਣ ਪਿੱਛੇ ਦੀ ਗਲਤੀ ਹੈ।
ਵਿਚਕਾਰਲੇ ਜੰਤਰ ਪੋਰਟ ਬਾਰੇ ਸਧਾਰਨ ਮਨਜ਼ੂਰੀ-ਜਾਂ-ਇਨਕਾਰ ਦਾ ਫੈਸਲਾ ਘੱਟ ਹੀ ਲੈਂਦੇ ਹਨ। ਬਹੁਤੇ ਪਹਿਲੇ ਬਾਈਟ ਜਾਂਚਦੇ ਹਨ, ਕੁਝ ਮੰਜ਼ਿਲ ਨੂੰ ਸਥਿਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਬਹੁਤ ਦੇਰ ਖੁੱਲ੍ਹੀਆਂ ਰਹਿਣ ਵਾਲੀਆਂ ਕਨੈਕਸ਼ਨਾਂ ਰੀਸੈਟ ਕਰਦੇ ਹਨ। ਇਸ ਲਈ ਇੱਕੋ ਪਰੋਫਾਈਲ ਇੱਕ ਨੈੱਟਵਰਕ ਤੋਂ ਚੱਲ ਸਕਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਤੋਂ ਸਮਾਂ-ਸਮਾਪਤੀ 'ਤੇ ਪਹੁੰਚ ਸਕਦੀ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਬਦਲਵੇਂ ਰਾਹ ਨੂੰ ਵਾਅਦੇ ਵਜੋਂ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਸਮਰਥਿਤ ਚੋਣ ਵਜੋਂ ਪਰਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਫਿਲਟਰ ਟ੍ਰੈਫਿਕ ਵੇਖਦਾ ਹੈ, ਪੋਰਟ ਨੰਬਰ ਉਹ ਪਹਿਲੀ ਚੀਜ਼ ਹੈ ਜਿਸ ਵੱਲ ਉਹ ਵੇਖਦਾ ਹੈ।
ਪਰੋਫਾਈਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤਾ ਪੱਕਾ ਕਰੋ
ਸਰਵਰ ਪੋਰਟ 'ਤੇ TCP ਲਈ ਸੰਰਚਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਪਰੋਫਾਈਲ ਨੇ ਉਹੀ ਢੋਆ-ਢੁਆਈ ਮੰਗਣੀ ਚਾਹੀਦੀ ਹੈ। UDP ਪਰੋਫਾਈਲ ਨੂੰ TCP ਮੰਗਣ ਲਈ ਮੁੜ ਲਿਖਣਾ ਸਰੋਤਾ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਇਸ ਤੋਂ ਬਣੀ ਸਮਾਂ-ਸਮਾਪਤੀ ਪੋਰਟ ਡਿੱਗਣ ਵਾਲੇ ਫਾਇਰਵਾਲ ਤੋਂ ਵੱਖਰੀ ਨਹੀਂ ਪਛਾਣੀ ਜਾ ਸਕਦੀ। ਓਪਰੇਟਰ ਦੀ ਆਪਣੀ TCP ਪਰੋਫਾਈਲ ਹੋਵੇ ਤਾਂ ਡਾਊਨਲੋਡ ਕਰੋ, ਕਿਉਂਕਿ ਕੁਝ ਸੇਵਾਵਾਂ ਹਰ ਢੋਆ-ਢੁਆਈ ਲਈ ਵੱਖਰਾ ਸਿਰਾ ਅਤੇ ਵੱਖਰੀ ਪਛਾਣ ਸੈਟਿੰਗ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ। ਹੱਥੀਂ ਸੋਧ ਨਿਯੰਤਰਿਤ ਪਰਖ ਲਈ ਠੀਕ ਹੈ ਅਤੇ ਸੇਵਾ ਦੇਣ ਵਾਲੇ ਦੀ ਮਨਸ਼ਾ ਦੀ ਸੰਰਚਨਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦਾ ਮਾੜਾ ਤਰੀਕਾ ਹੈ।
ਉਸ ਮੇਲ ਦੇ ਦੋਵੇਂ ਪਾਸੇ ਸੰਰਚਨਾ ਵਿੱਚ ਦਿਸਦੇ ਹਨ, ਅਤੇ OpenVPN ਪ੍ਰੋਜੈਕਟ ਦੇ ਲਿੰਕ ਵਿਕਲਪ ਦੋਵੇਂ ਰੂਪ ਦਰਜ ਕਰਦੇ ਹਨ। ਘੱਟੋ-ਘੱਟ ਜੋੜੀ ਇੰਝ ਦਿਸਦੀ ਹੈ:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਬਦਲਵਾਂ ਰਾਹ ਲਾਹੇਵੰਦ ਹੈ ਜਾਂ ਨਹੀਂ
ਪਹਿਲੀ ਸ਼ਰਤ ਇਹ ਹੈ ਕਿ ਓਪਰੇਟਰ ਉਹ ਢੋਆ-ਢੁਆਈ ਬਿਲਕੁਲ ਦਿੰਦਾ ਹੈ; ਉਹ ਨਾ ਹੋਵੇ ਤਾਂ ਬਾਕੀ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਮਹੱਤਵ ਨਹੀਂ। ਦੂਜੀ ਇਹ ਹੈ ਕਿ ਰਾਹ ਲੰਮੇ ਸਮੇਂ ਦਾ ਸੈਸ਼ਨ ਜੀਵਤ ਰੱਖਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੁਝ ਨੈੱਟਵਰਕ ਪੋਰਟ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਲਾਕ ਕਰਨ ਦੀ ਥਾਂ ਖੁੱਲ੍ਹੀਆਂ ਰਹਿਣ ਵਾਲੀਆਂ ਕਨੈਕਸ਼ਨਾਂ ਰੀਸੈਟ ਕਰਦੇ ਹਨ। ਤੀਜੀ ਇਹ ਹੈ ਕਿ ਬਦਲਵਾਂ ਰਾਹ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਅਪਵਾਦ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ਵੱਲੋਂ ਨਾ ਸੁਧਾਰੀ ਗਈ ਖਰਾਬੀ ਲੁਕਾਉਣ ਵਾਲਾ ਅਸਥਾਈ ਉਪਾਅ।
ਹਰ ਸ਼ਰਤ ਦੀ ਇੱਕ ਸਸਤੀ ਜਾਂਚ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ 'ਤੇ ਫੇਲ ਹੋਣਾ ਕਲਾਇੰਟ ਵੱਲੋਂ ਇੱਕੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
ਢੋਆ-ਢੁਆਈਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੈਪਟਿਵ ਪੋਰਟਲ 'ਤੇ ਕੋਈ ਵੀ ਸਾਈਨ-ਇਨ ਪੂਰਾ ਕਰੋ। ਜਿਸ ਨੈੱਟਵਰਕ ਨੇ ਤੁਹਾਡਾ ਜੰਤਰ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ, ਉਹ ਦੋਵੇਂ ਢੋਆ-ਢੁਆਈਆਂ ਬਲਾਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਤਦ ਤੁਲਨਾ ਸੁਰੰਗ ਨਹੀਂ, ਪੋਰਟਲ ਮਾਪਦੀ ਹੈ। ਸਾਈਨ ਇਨ ਕਰੋ, ਪੱਕਾ ਕਰੋ ਕਿ ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਚੱਲਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਪਰਖ ਸ਼ੁਰੂ ਕਰੋ।
ਤੁਸੀਂ ਜੋ ਕੀਮਤ ਮੰਨਦੇ ਹੋ: TCP ਦੇ ਅੰਦਰ TCP
TCP ਗੁੰਮ ਹੋਏ ਖੰਡ ਮੁੜ ਭੇਜਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦਾ ਕ੍ਰਮ ਕਾਇਮ ਰੱਖਦਾ ਹੈ। ਜਦੋਂ ਆਪਣਾ ਵੀ TCP ਵਰਤਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ TCP ਸੁਰੰਗ ਦੇ ਅੰਦਰ ਚੱਲਦੀ ਹੈ, ਦੋ ਰਿਕਵਰੀ ਪਰਤਾਂ ਇੱਕੋ ਨੁਕਸਾਨ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਇਹੀ ਆਪਸੀ ਕਿਰਿਆ ਸੁਰੰਗ ਨੂੰ ਨੁਕਸਾਨ ਵਾਲੇ ਰਾਹ 'ਤੇ ਹੌਲੀ ਮਹਿਸੂਸ ਕਰਾਉਂਦੀ ਹੈ। ਲੱਛਣ ਸਾਫ਼ ਫੇਲ ਹੋਣਾ ਨਹੀਂ, ਦੇਰੀ ਅਤੇ ਕੰਬਣੀ ਹੈ, ਜੋ ਦੂਰਲੇ ਸਿਰੇ ਨੂੰ ਦੋਸ਼ ਦੇਣਾ ਸੌਖਾ ਬਣਾਉਂਦੀ ਹੈ। ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਤੋਂ ਦੋਵੇਂ ਢੋਆ-ਢੁਆਈਆਂ ਵਿੱਚ ਮਾਪੋ।
UDP ਇਸ ਨੈਸਟਿੰਗ ਤੋਂ ਬਚਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਮੁੱਖ ਕਾਰਨ ਹੈ ਕਿ ਓਪਰੇਟਰ ਇਸਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹਨ ਅਤੇ TCP ਸਿਰਫ਼ ਬਦਲ ਵਜੋਂ ਦਿੰਦੇ ਹਨ। ਸਥਿਰ TCP ਕਨੈਕਸ਼ਨ ਫਿਰ ਵੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ UDP ਕਨੈਕਸ਼ਨ ਨਾਲੋਂ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਹੈ, ਇਸ ਲਈ ਤੁਲਨਾ ਚੰਗੀ ਅਤੇ ਮਾੜੀ ਚੋਣ ਵਿਚਕਾਰ ਨਹੀਂ, ਦੋ ਅਸਲ ਲਾਗਤਾਂ ਵਿਚਕਾਰ ਹੈ। ਤੁਲਨਾ ਕਰਦਿਆਂ ਜੰਤਰ ਅਤੇ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਅਣ-ਬਦਲਿਆ ਰੱਖੋ, ਨਹੀਂ ਤਾਂ ਨਤੀਜਾ ਗਲਤ ਚਰ ਵਰਣਨ ਕਰੇਗਾ।
ਕੁਝ ਕਲਾਇੰਟ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸਿਰਫ਼ ਇੱਕ ਢੋਆ-ਢੁਆਈ ਲਈ ਦਰਜ ਹਨ, ਇਸ ਲਈ ਬਦਲਵਾਂ ਪਰੋਫਾਈਲ ਉਹ ਵਿਵਹਾਰ ਚੁੱਪਚਾਪ ਛੱਡ ਸਕਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਟਿਕੇ ਸੀ। TCP ਪਰੋਫਾਈਲ ਨੂੰ ਸਿੱਧੀ ਅਦਲਾ-ਬਦਲੀ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਚੋਣ ਦੀ ਢੋਆ-ਢੁਆਈ ਲੋੜ ਪੜ੍ਹੋ।
ਉਹ ਖਰਾਬੀਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਦੂਜੀ ਢੋਆ-ਢੁਆਈ ਛੂਹਦੀ ਨਹੀਂ
ਮਿਆਦ ਪੁੱਗਿਆ ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਵੀ ਘੜੀ ਜਾਂਚ ਜਾਂ ਨਵੀਨੀਕਰਨ ਮੰਗਦਾ ਹੈ, ਅਤੇ ਰੱਦ ਕੀਤਾ ਖਾਤਾ ਅਜੇ ਵੀ ਸਹੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਮੰਗਦਾ ਹੈ। ਓਪਰੇਟਰ ਵੱਲੋਂ ਦਿੱਤੀਆਂ ਸਰਵਰ-ਪਛਾਣ ਜਾਂਚਾਂ ਰੱਖੋ, ਕਿਉਂਕਿ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਪੋਰਟ ਨੰਬਰ ਕਿਸੇ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦਾ। ਜੋ ਪੋਰਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਉਹ ਸਿਰਫ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਕੁਝ ਸੁਣ ਰਿਹਾ ਹੈ।
ਜੇ ਸੁਰੰਗ ਉੱਪਰ ਆ ਜਾਵੇ ਅਤੇ ਮੰਜ਼ਿਲਾਂ ਫਿਰ ਵੀ ਫੇਲ ਹੋਣ, ਤਾਂ ਬਚੀ ਸਮੱਸਿਆ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਦੀ ਰਾਊਟਿੰਗ ਜਾਂ ਨਾਮ-ਹੱਲ ਹੈ, ਢੋਆ-ਢੁਆਈ ਨਹੀਂ। ਪੋਰਟ ਬਦਲਦਿਆਂ ਘੁੰਮਣ ਦੀ ਥਾਂ ਉਸ ਰਾਹ ਨੂੰ ਅਪਣਾਓ, ਕਿਉਂਕਿ ਇੰਝ ਹੀ ਇੱਕ ਦੁਪਹਿਰ ਗੁਆਚਦੀ ਹੈ। ਪਰੋਫਾਈਲ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਢੋਆ-ਢੁਆਈ ਅਜ਼ਮਾਉਣੀ ਹੈ; ਇਹ ਕਦੇ ਨਹੀਂ ਦੱਸਦੀ ਕਿ UDP ਰਾਹ ਕਿਉਂ ਫੇਲ ਹੋਇਆ।