ਹੌਟਸਪੌਟ ਰਾਹੀਂ PPTP: TCP 1723 ਸਿਰਫ਼ ਅੱਧਾ ਹੈ

ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ: ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਖੁੱਲ੍ਹਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, GRE ਰਾਹ ਵਿੱਚ ਟਿਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਰਵਰ ਕਾਲ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਣ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। PPTP ਕਲਾਇੰਟ ਨੂੰ 1723 ਉੱਤੇ TCP ਸੈਸ਼ਨ ਅਤੇ ਡੇਟਾ ਢੋਣ ਵਾਲਾ GRE ਰਾਹ ਦੋਵੇਂ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਹੌਟਸਪੌਟ ਇੱਕ ਨੂੰ ਲੰਘਾ ਕੇ ਦੂਜੇ ਨੂੰ ਡੇਗ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਕਰਨ ਨਾਲ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਹੱਦ ਦੀ ਜਾਂਚ ਕਰਨੀ ਹੈ। Windows ਦੇ ਗਲਤੀ ਨੰਬਰ ਤੁਹਾਡੇ ਲਈ ਇਹ ਨਹੀਂ ਕਰਦੇ।

GRE IP ਪ੍ਰੋਟੋਕੋਲ 47 ਹੈ। ਇਹ TCP ਜਾਂ UDP ਪੋਰਟ 47 ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹੀ ਫ਼ਰਕ ਫਾਇਰਵਾਲਾਂ ਬਾਰੇ ਜ਼ਿਆਦਾਤਰ ਉਲਝਣ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।

ਦੋ ਰਾਹ, ਇੱਕ ਕਨੈਕਸ਼ਨ

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

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

ਹੌਟਸਪੌਟ ਦੋ ਹੋਰ ਹੱਦਾਂ ਜੋੜਦਾ ਹੈ

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

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

807 ਨੂੰ ਫ਼ੈਸਲਾ ਨਹੀਂ, ਰੁਕਾਵਟ ਵਜੋਂ ਪੜ੍ਹੋ

Windows 807 ਨੂੰ ਵਿਘਨ ਪਏ ਕਨੈਕਸ਼ਨ ਵਜੋਂ ਦੱਸਦਾ ਹੈ, ਜੋ ਕਾਰਨ ਦੀ ਥਾਂ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਇਸਦੀ ਗਲਤੀ ਸਾਰਣੀ 806 ਨੂੰ GRE-ਸੰਬੰਧੀ ਸ਼੍ਰੇਣੀ ਵਜੋਂ ਵੱਖ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫ਼ਰਕ ਜਾਣਨਾ ਯੋਗ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨੰਬਰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਆਪਰੇਟਰ ਨੇ ਪ੍ਰੋਟੋਕੋਲ 47 ਫਿਲਟਰ ਕੀਤਾ, ਸਰਵਰ ਦੀ ਸਮਰੱਥਾ ਖ਼ਤਮ ਹੋਈ, ਜਾਂ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਸਹੀ ਸਨ। ਗਲਤੀ ਕਹਿੰਦੀ ਹੈ ਕਿ ਸੈਸ਼ਨ ਖ਼ਤਮ ਹੋਇਆ; ਰਾਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿੱਥੇ।

ਹੌਟਸਪੌਟ ਉੱਤੇ ਸਫਲ ਬਰਾਊਜ਼ਰ ਟੈਸਟ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਆਮ ਐਪਲੀਕੇਸ਼ਨ ਰਾਹ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ GRE ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।

ਅਸਫਲ ਹੋਇਆ ਪੜਾਅ ਵੱਖ ਕਰੋ

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

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

ਨਿਰੰਤਰ ਪਹੁੰਚ ਲਈ, VPN ਦੇ ਮਾਲਕ ਨਾਲ ਸਮਰਥਿਤ ਮਾਈਗ੍ਰੇਸ਼ਨ ਉੱਤੇ ਸਹਿਮਤ ਹੋਵੋ। ਚੈੱਕਲਿਸਟ ਕਿਸੇ ਉਪਾਅ ਦੀ ਥਾਂ ਫ਼ੈਸਲੇ ਨਾਲ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ।