PPTP ਪਾਸਥਰੂ ਗਾਇਬ: Windows VPN ਗਲਤੀ 807 ਠੀਕ ਕਰੋ

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

ਪੋਰਟ ਟੇਬਲ ਵਿੱਚ ਪਰੋਟੋਕਾਲ ਨੰਬਰ ਲਈ ਕੋਈ ਕਤਾਰ ਨਹੀਂ ਹੁੰਦੀ

PPTP ਦੋ ਗੱਲਬਾਤਾਂ ਵਰਤਦਾ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ। TCP 1723 ਵਾਲੀ ਕਾਲ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਲਿੰਕ ਦੀ ਜਾਣਕਾਰੀ ਭੇਜਦੀ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੇ ਡਿਸਕਨੈਕਟ ਹੋਣ 'ਤੇ ਉਸਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਪੇਲੋਡ ਪਾਸਾ GRE ਦੇ ਅੰਦਰ ਚੱਲਦਾ ਹੈ, ਜਿਸਨੂੰ IP ਹੈਡਰ ਪਰੋਟੋਕਾਲ ਨੰਬਰ 47 ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਟਨਲ ਦੇ ਅੰਦਰ PPP ਲਿੰਕ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਜਦਕਿ MS-CHAPv2 ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਾਂਚਦਾ ਹੈ।

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

ਡੇਟਾ ਮਾਰਗ ਮਰਨ 'ਤੇ Windows ਕੀ ਦੱਸਦਾ ਹੈ

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

ਪਾਸਵਰਡ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਟਰਾਂਸਪੋਰਟ 'ਤੇ ਕੰਮ ਕਰੋ। 807 ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਲਈ ਪ੍ਰਮਾਣ ਪੱਤਰ ਬਦਲਣ ਨਾਲ ਅਸਲ ਖ਼ਰਾਬੀ ਆਪਣੀ ਥਾਂ 'ਤੇ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਪੜ੍ਹਨਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।

ਦੂਜਾ ਕਲਾਇੰਟ ਚੱਲ ਰਹੀ ਟਨਲ ਕਿਉਂ ਤੋੜਦਾ ਹੈ

ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਲਈ ਪੋਰਟ ਨਾ ਹੋਣ ਕਰਕੇ, NAT ਯੰਤਰ ਦੋ PPTP ਕਲਾਇੰਟਾਂ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਿਵੇਂ ਦੋ HTTPS ਸੈਸ਼ਨਾਂ ਨੂੰ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ ਬਹੁਤ ਸਾਰੇ ਖਪਤਕਾਰ ਯੰਤਰ ਇੱਕ ਹੀ PPTP ਕਾਲ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ ਅਤੇ ਸਰੋਤ ਪਤੇ ਰਾਹੀਂ ਉਸਦਾ ਪਤਾ ਰੱਖਦੇ ਹਨ। ਜੋ ਲੈਪਟਾਪ ਇਕੱਲਾ ਚੱਲਦਾ ਸੀ ਉਹ ਦੂਜੀ ਮਸ਼ੀਨ ਦੇ ਡਾਇਲ ਕਰਦਿਆਂ ਹੀ ਪੂਰਾ ਹੋਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਪਾਸਿਓਂ ਅਸਫ਼ਲਤਾ ਬੇਤਰਤੀਬ ਲੱਗਦੀ ਹੈ। ਇਹ ਪੈਟਰਨ ਫ਼ਰਮਵੇਅਰ ਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਪਰੋਫ਼ਾਈਲ ਬਦਲਾਅ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲੇਗਾ।

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

ਸਾਬਿਤ ਕਰੋ ਕਿ ਕਿਹੜਾ ਅੱਧ ਫੇਲ੍ਹ ਹੋ ਰਿਹਾ ਹੈ

ਰਾਊਟਰ 'ਤੇ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ TCP 1723 ਪਹੁੰਚ ਰਿਹਾ ਹੈ, ਕਿਉਂਕਿ ਉਹੀ ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਅੱਧ ਜਾਂਚ ਰਹੇ ਹੋ। ਇਹ Windows ਕਲਾਇੰਟ ਤੋਂ ਆਪਣੇ ਸਰਵਰ ਨਾਮ ਦੇ ਖ਼ਿਲਾਫ਼ ਚਲਾਓ। ਪਹਿਲਾ ਛਾਪਦਾ ਹੈ ਕਿ ਪੋਰਟ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਦੂਜਾ ਬਿਨਾਂ ਕਿਸੇ ਸੰਵਾਦ ਦੇ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਵਾਰ-ਵਾਰ ਕੀਤੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਤੁਲਨਾਯੋਗ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

Wireshark ਵਿੱਚ ਇਸਦਾ ਬਰਾਬਰ ਡਿਸਪਲੇ ਫ਼ਿਲਟਰ ip proto 47 ਹੈ, ਜਿਸਨੂੰ ਕਮਾਂਡ ਲਾਈਨ ਵਿੱਚ ਸੁਵਿਧਾਜਨਕ ਨਾ ਹੋਣ ਵਾਲੇ ਵਿਅਕਤੀ ਨੂੰ ਦੇਣਾ ਸੌਖਾ ਹੈ। ਜਵਾਬ ਵਿੱਚ ਕੁਝ ਵੀ ਬਾਹਰ ਨਾ ਜਾਂਦਿਆਂ GRE ਆਉਣਾ ਮਤਲਬ ਹੈ ਕਿ ਵਾਪਸੀ ਮਾਰਗ ਸੁਧਾਰਨਾ ਪਵੇਗਾ।

ਗਲਤੀ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਸੁਧਾਰਦਾ ਹੈ

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP ਬਦਲਣਾ ਦੂਜਾ ਵਿਕਲਪ ਹੈ ਅਤੇ ਅਕਸਰ ਸਸਤਾ ਹੁੰਦਾ ਹੈ। ਜੋ ਰਾਊਟਰ ਆਪ VPN ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਉਹ ਆਉਣ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਲਈ ਦੋਹਰੇ NAT ਤੋਂ ਬਚਦਾ ਹੈ, ਅਤੇ ਜਿਸ ਪਰੋਟੋਕਾਲ ਨੂੰ ਪੋਰਟ-ਆਧਾਰਿਤ NAT ਪਹਿਲਾਂ ਹੀ ਸੰਭਾਲਦਾ ਹੈ ਉਸਨੂੰ ਪਾਸਥਰੂ ਦੀ ਲੋੜ ਹੀ ਨਹੀਂ: UDP 'ਤੇ OpenVPN, TCP 443 'ਤੇ SSTP, ਜਾਂ ESP ਨੂੰ UDP 4500 ਵਿੱਚ ਲਪੇਟਣ ਵਾਲੇ NAT-T ਨਾਲ L2TP/IPsec। PPTP MS-CHAPv2 'ਤੇ ਵੀ ਨਿਰਭਰ ਹੈ, ਜਿਸਦੀਆਂ ਦਰਜ ਕਮਜ਼ੋਰੀਆਂ ਗਲਤੀ ਦੂਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਇਸਨੂੰ ਨਵੀਂ ਤੈਨਾਤੀ ਲਈ ਮਾੜੀ ਚੋਣ ਬਣਾਉਂਦੀਆਂ ਹਨ।

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