ਘਰੇਲੂ ਰਾਊਟਰ ਦੇ ਪਿੱਛੇ PPTP ਸਰਵਰ: ਪਹਿਲਾਂ 1723 ਅਤੇ GRE ਠੀਕ ਕਰੋ
ਘਰੇਲੂ ਰਾਊਟਰ ਦੇ ਪਿੱਛੇ PPTP ਚਲਾਓ: TCP 1723, IP ਪ੍ਰੋਟੋਕੋਲ 47, ਪਾਸਥਰੂ ਚੈਕਬਾਕਸ ਅਤੇ MTU ਦਾ ਗਣਿਤ, ਤੇ ਕਦੋਂ L2TP ਜਾਂ OpenVPN ਵਧੀਆ ਸੌਦਾ ਹੈ।
ਘਰੇਲੂ ਰਾਊਟਰ ਦੇ ਪਿੱਛੇ PPTP ਦੋ ਅਸੰਬੰਧਿਤ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਪੂਰੀ ਸ਼ਾਮ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਇੱਕ ਫੇਲ੍ਹ ਫਾਰਵਰਡਿੰਗ ਦਾ ਖਾਲੀ ਥਾਂ ਹੈ: ਰਾਊਟਰ TCP 1723 ਲੰਘਾਉਂਦਾ ਹੈ ਤੇ IP ਪ੍ਰੋਟੋਕੋਲ 47 ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਤਰੁੱਟੀ 619 'ਤੇ ਅਟਕ ਜਾਂਦਾ ਹੈ। ਦੂਜੀ ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਹੈ: ਟਨਲ ਉੱਪਰ ਆਉਂਦੀ ਹੈ, ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੀ ਹੈ, ਤੇ ਫਿਰ ਪੂਰੇ ਆਕਾਰ ਦਾ ਪੈਕੇਟ ਲੰਘਣ ਵੇਲੇ ਜੰਮ ਜਾਂਦੀ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜਾ ਹੈ, ਇਹ ਪਤਾ ਲਾਉਣਾ ਪਹਿਲਾ ਅਸਲੀ ਕਦਮ ਹੈ; ਬਾਕੀ ਤੁਹਾਡਾ ਰਾਊਟਰ ਕੀ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ ਹੈ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ, ਕਿਹੜਾ ਬ੍ਰਾਂਡ ਵਧੀਆ ਹੈ ਦੀ ਨਹੀਂ।
ਦੋ ਵਾਹਕ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਕੋਲ ਪੋਰਟ ਹੈ
PPTP ਦੋ ਵਾਹਕਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ: TCP 1723 'ਤੇ ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ, ਅਤੇ ਵਿਸਤ੍ਰਿਤ GRE ਵਿੱਚ ਲਪੇਟੇ PPP ਫਰੇਮ, ਯਾਨੀ IP ਪ੍ਰੋਟੋਕੋਲ 47। GRE ਕੋਲ ਪੋਰਟ ਨੰਬਰ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਪੋਰਟ 1723 ਫਾਰਵਰਡ ਵਜੋਂ ਲਿਖਿਆ ਨਿਯਮ ਇਸ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਵੈੱਬ ਇੰਟਰਫ਼ੇਸ ਉਸ ਖੇਤਰ ਨੂੰ ਜੋ ਵੀ ਨਾਮ ਦੇਵੇ। ਖਪਤਕਾਰ ਰਾਊਟਰ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਟੋਕੋਲ ਨਿਯਮ ਦੀ ਥਾਂ PPTP ਪਾਸਥਰੂ ਨਾਮ ਦਾ ਚੈਕਬਾਕਸ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਚੈਕਬਾਕਸ ਦੋ ਕੰਮ ਕਰਦਾ ਹੈ: ਫਾਇਰਵਾਲ ਵਿੱਚੋਂ ਪ੍ਰੋਟੋਕੋਲ 47 ਲੰਘਣ ਦਿੰਦਾ ਹੈ ਤੇ NAT ਨੂੰ GRE ਪ੍ਰਵਾਹ ਟਰੈਕ ਕਰਨਾ ਸਿਖਾਉਂਦਾ ਹੈ। ਲੀਨਕਸ ਰਾਊਟਰ 'ਤੇ ਉਹ ਕੰਮ ਵੱਖਰੇ ਮਾਡਿਊਲ ਤੇ ਵੱਖਰੇ ਨਿਯਮ ਹਨ, ਇਸ ਲਈ ਅੱਧ-ਸੰਰਚਿਤ ਪਾਸਥਰੂ ਵੀ ਕੰਮ ਕਰਦਾ ਨਿਯੰਤਰਣ ਚੈਨਲ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਅੱਧਾ ਮੌਜੂਦ ਹੈ।
ਸਰਵਰ ਦੀ ਆਪਣੀ ਫਾਇਰਵਾਲ ਨੂੰ ਵੀ ਰਾਊਟਰ ਦੇ ਪਤੇ ਤੋਂ ਪ੍ਰੋਟੋਕੋਲ 47 ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੋ ਹੋਸਟ ਫਾਇਰਵਾਲ ਸਿਰਫ਼ 1723/tcp ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਉਹ LAN ਦੇ ਅੰਦਰੋਂ ਤਰੁੱਟੀ 619 ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਟੁੱਟੀ ਫਾਰਵਰਡਿੰਗ ਤੇ ਟੁੱਟਿਆ ਹੋਸਟ ਨਿਯਮ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ।
sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'ਜੇ ਮਾਡਿਊਲ ਨਹੀਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre ਨਾਲ ਲੋਡ ਕਰੋ ਤੇ ਲੋਡਿੰਗ ਪੱਕੀ ਕਰੋ, ਕਿਉਂਕਿ ਸਹਾਇਕ ਭੁੱਲਣ ਵਾਲਾ ਰੀਬੂਟ ਕੰਮ ਕਰਦੀ ਟਨਲ ਨੂੰ ਫਿਰ ਤਰੁੱਟੀ 619 ਬਣਾ ਦਿੰਦਾ ਹੈ। ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ 47 ਸਿਰਫ਼ ਸਰਵਰ ਦੇ ਪਤੇ ਵੱਲ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਪੂਰਾ LAN ਨਹੀਂ। RFC 2637 ਪਰਿਭਾਸ਼ਾ ਨਿਯੰਤਰਣ ਤੇ ਡੇਟਾ ਮਾਰਗ ਨੂੰ ਵੱਖ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਇੱਕ ਪੋਰਟ ਫਾਰਵਰਡ ਸਕ੍ਰੀਨ PPTP ਦਾ ਪੂਰਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦੀ।
ਪਾਸਥਰੂ ਚੈਕਬਾਕਸ ਜਾਂ ਸਪੱਸ਼ਟ ਪ੍ਰੋਟੋਕੋਲ ਨਿਯਮ
ਸਿਰਫ਼ ਫਾਇਰਵਾਲ ਖੋਲ੍ਹਣ ਵਾਲਾ ਪਾਸਥਰੂ ਚੈਕਬਾਕਸ ਕਾਲ ਪਛਾਣਕਰਤਾ ਮੁੜ ਲਿਖਣ ਵਾਲੇ ALG ਨਾਲੋਂ ਸਹੀ ਦੇ ਵਧੇਰੇ ਨੇੜੇ ਹੈ। ਫਾਇਰਵਾਲ ਵਾਲਾ ਅੱਧਾ ਹਿੱਸਾ ਅਨੁਮਾਨਯੋਗ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰੋਟੋਕੋਲ 47 ਜਾਂ ਤਾਂ ਸਵੀਕਾਰ ਹੁੰਦਾ ਹੈ ਜਾਂ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ, ਤੇ ਕਾਊਂਟਰ ਦੱਸਦੇ ਹਨ ਕਿਹੜਾ। ਮੁੜ ਲਿਖਣ ਵਾਲਾ ਅੱਧਾ ਹਿੱਸਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਨਿਰਮਾਤਾ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ PPTP ਦੇ ਕਾਲ ਪਛਾਣਕਰਤਾ ਹਰ ਟਨਲ ਲਈ ਹੁੰਦੇ ਹਨ ਤੇ ਉਹਨਾਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਵਾਲੇ NAT ਨੂੰ ਛੋਹੇ ਹਰ ਕਾਲ ਦਾ ਪਿੱਛਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਕਲਾਇੰਟ ਜੁੜਦਾ ਹੈ ਤੇ ਦੋ ਨਹੀਂ, ALG ਪਹਿਲਾ ਸ਼ੱਕੀ ਹੁੰਦਾ ਹੈ।
1723 ਲਈ ਮੰਜ਼ਿਲ NAT ਨਿਯਮ ਵਿੱਚ ਵੀ ਮਾਲਕੀ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਜੇ ਪੁਰਾਣਾ ਨਿਯਮ ਅਜੇ ਵੀ 1723 ਉਸ ਹੋਸਟ ਨੂੰ ਭੇਜਦਾ ਹੈ ਜਿਸ ਨੇ ਸਰਵਰ ਚਲਾਉਣਾ ਬੰਦ ਕੀਤਾ ਹੈ, ਤਾਂ ਪੈਕੇਟ ਬੰਦ ਪੋਰਟ 'ਤੇ ਡਿੱਗਦੇ ਹਨ ਤੇ ਰਾਊਟਰ ਦੀ ਆਪਣੀ PPTP ਸੇਵਾ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ, ਜੋ ਫਾਇਰਵਾਲ ਫੇਲ੍ਹ ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ ਪੁਰਾਣਾ ਟਾਰਗੇਟ ਹੈ। ਦੂਜਾ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਤੇ ਉਸ ਦੀ ਮੰਜ਼ਿਲ ਪੜ੍ਹੋ। ਜੋ ਰਾਊਟਰ ਆਪ PPTP ਖ਼ਤਮ ਕਰਦੇ ਹਨ, ਉੱਥੇ WAN ਨਿਯਮ ਅੰਤਰ-ਨਿਰਮਿਤ ਸੇਵਾ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ 1723 ਤੇ ਪ੍ਰੋਟੋਕੋਲ 47 ਲਈ ਇੱਕ ਮਾਲਕ ਚੁਣੋ।
ਇੱਕੋ NAT ਪਿੱਛੇ ਦੋ ਕਲਾਇੰਟ ਉਹ ਸਥਿਤੀ ਹੈ ਜੋ ਸਧਾਰਨ ਫਾਰਵਰਡਿੰਗ ਨੂੰ ਚਤੁਰ ਫਾਰਵਰਡਿੰਗ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। ਕਾਲ ਪਛਾਣਕਰਤਾ ਮੁੜ ਲਿਖੇ ਬਿਨਾਂ ਪ੍ਰੋਟੋਕੋਲ 47 ਫਾਰਵਰਡ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੇ ਸਹਾਇਕ ਨਾਲੋਂ ਵਧੀਆ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ।
ਰਾਊਟਰ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਮਾਪੋ
PPTP ਲਾਭਕਾਰੀ ਪੇਲੋਡ ਘਟਾਉਂਦਾ ਹੈ, ਤੇ ਇਹ ਘਟਾਅ ਗਣਿਤ ਹੈ, ਕੋਈ ਰਹੱਸ ਨਹੀਂ। ਹਰ ਟਨਲ ਪੈਕੇਟ ਬਾਹਰੀ IP ਹੈਡਰ, ਵਿਸਤ੍ਰਿਤ GRE ਹੈਡਰ, PPP ਹੈਡਰ ਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਾਲ MPPE ਹੈਡਰ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ। ਜਦੋਂ ਮਾਰਗ ਨਤੀਜੇ ਵਜੋਂ ਬਣਿਆ ਫਰੇਮ ਲੈ ਕੇ ਨਹੀਂ ਚੱਲ ਸਕਦਾ, ਛੋਟੇ ਪੈਕੇਟ ਲੰਘ ਜਾਂਦੇ ਹਨ, ਲਾਗਇਨ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਤੇ ਫਾਇਲ ਟ੍ਰਾਂਸਫਰ ਜਾਂ TLS ਹੈਂਡਸ਼ੇਕ ਪਹਿਲੀ ਵਾਰ ਪੂਰੇ ਆਕਾਰ ਦਾ ਪੈਕੇਟ ਭੇਜਣ 'ਤੇ ਸੈਸ਼ਨ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਸੰਖਿਆ ਗਿਣੋ। ਵਿਸਤ੍ਰਿਤ GRE ਲਈ 8 ਬਾਈਟ, PPP ਲਈ 4, MPPE ਲਈ 4, ਤੇ ਬਾਹਰੀ IP ਹੈਡਰ ਲਈ 20 ਲੱਗਦੇ ਹਨ, ਇਸ ਲਈ ਟਨਲ ਕਿਸੇ ਵੀ ਪੇਲੋਡ ਤੋਂ ਪਹਿਲਾਂ 36 ਬਾਈਟ ਖਾ ਜਾਂਦੀ ਹੈ। 1492 'ਤੇ ਖ਼ਤਮ ਹੋਣ ਵਾਲੇ PPPoE WAN 'ਤੇ ਸਭ ਤੋਂ ਵੱਡਾ PPP MTU ਜੋ ਬੈਠਦਾ ਹੈ, 1492 ਘਟਾ 36 ਹੈ, ਯਾਨੀ 1456। PPP ਵਿਕਲਪਾਂ ਵਿੱਚ mtu ਤੇ mru ਨੂੰ ਉਸ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕਰੋ ਤੇ ਟੁਕੜੇ ਨਾ ਕਰਨ ਵਾਲੇ ਪਿੰਗ ਨਾਲ ਮੁੜ ਜਾਂਚੋ।
ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpdਪਿੰਗ ਮਾਰਗ ਮਾਪਦਾ ਹੈ, ਟਨਲ ਨਹੀਂ: 1464 ਬਾਈਟ ਪੇਲੋਡ ਤੇ 28 ਬਾਈਟ IP ਤੇ ICMP ਹੈਡਰ ਮਿਲ ਕੇ 1492 ਬਾਈਟ ਦਾ ਫਰੇਮ ਠੀਕ ਭਰਦੇ ਹਨ। ਜੇ ਉਹ ਪਿੰਗ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਸੰਖਿਆ ਘਟਾਉਂਦੇ ਜਾਓ ਜਦ ਤੱਕ ਲੰਘ ਨਹੀਂ ਜਾਂਦੀ, ਫਿਰ ਨਤੀਜੇ ਵਿੱਚੋਂ 36 ਘਟਾਓ। ਮਾਰਗ ਦੀ ਹੱਦ ਤੋਂ ਉੱਪਰ ਸੈੱਟ ਕੀਤੀ ਟਨਲ MTU ਆਕਾਰ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੀ ਇੱਕ ਵੀ ਲਾਗ ਲਾਈਨ ਤੋਂ ਬਿਨਾਂ ਜੰਮਣ ਪੈਦਾ ਕਰਦੀ ਹੈ।
ਇੱਕੋ ਰਾਊਟਰ 'ਤੇ PPTP, L2TP/IPsec ਜਾਂ OpenVPN
ਇੱਕੋ ਰਾਊਟਰ ਤਿੰਨ ਆਮ ਟਨਲਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲੈ ਕੇ ਚੱਲ ਸਕਦਾ ਹੈ, ਤੇ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਉਸ ਨੂੰ ਕੀ ਪ੍ਰਗਟ ਕਰਨਾ ਹੈ। PPTP ਲਈ ਦੋ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਵਿੱਚ ਦੋ ਨਿਯਮ ਚਾਹੀਦੇ ਹਨ। IPsec ਉੱਤੇ L2TP ਲਈ ਕੁੰਜੀ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਵਾਸਤੇ UDP 500 ਤੇ 4500 ਚਾਹੀਦੇ ਹਨ, ਤੇ NAT-T ਇਸ ਨੂੰ ਨਾ ਲੈ ਕੇ ਚੱਲੇ ਤਾਂ ਪੇਲੋਡ ਲਈ ਪ੍ਰੋਟੋਕੋਲ 50 ਚਾਹੀਦਾ ਹੈ। OpenVPN ਲਈ ਇੱਕ UDP ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ ਤੇ ਕੋਈ ਸਹਾਇਕ ਨਹੀਂ।
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
L2TP ਦਾ ਕਾਲਮ ਆਪਣੇ ਆਪ GRE ਨਾਲੋਂ ਵਧੇਰੇ ਮਿੱਤਰਵਾਨ ਨਹੀਂ ਹੁੰਦਾ। ESP IP ਪ੍ਰੋਟੋਕੋਲ 50 ਹੈ ਤੇ ਇਸ ਦਾ ਵੀ ਪੋਰਟ ਨਹੀਂ, ਇਸ ਲਈ ਪ੍ਰੋਟੋਕੋਲ 47 ਨਾਲ ਦਿੱਕਤ ਹੋਣ ਵਾਲੇ ਰਾਊਟਰ ਨੂੰ ਉਸੇ ਕਾਰਨ ਪ੍ਰੋਟੋਕੋਲ 50 ਨਾਲ ਵੀ ਦਿੱਕਤ ਹੋ ਸਕਦੀ ਹੈ। NAT-T ESP ਨੂੰ UDP 4500 ਦੇ ਅੰਦਰ ਲਪੇਟਣ ਲਈ ਹੈ, ਤੇ ਜਦੋਂ ਦੋਵੇਂ ਸਿਰੇ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਤਾਂ ਪ੍ਰੋਟੋਕੋਲ 50 ਦਾ ਨਿਯਮ ਬੇਲੋੜਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਿਰਿਆਂ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਰਾਊਟਰ ਦੇ PPTP ਚੈਕਬਾਕਸ ਦੀ ਨਹੀਂ। ਦੋਵਾਂ ਲਈ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਤੈਅ ਕੀਤਾ ਹੈ।
OpenVPN ਰਾਊਟਰ ਵੱਲ ਸਭ ਤੋਂ ਘੱਟ ਚੱਲਦੇ ਹਿੱਸਿਆਂ ਵਾਲਾ ਵਿਕਲਪ ਹੈ। ਇੱਕ UDP ਪੋਰਟ, ਇੱਕ ਫਾਰਵਰਡਿੰਗ, ਕੋਈ ਕਨੈਕਸ਼ਨ-ਟ੍ਰੈਕਿੰਗ ਸਹਾਇਕ ਨਹੀਂ ਤੇ ਕਾਲ ਪਛਾਣਕਰਤਾ ਦਾ ਕੋਈ ਮੁੜ-ਲੇਖ ਨਹੀਂ। ਸੌਦਾ ਇਹ ਹੈ ਕਿ ਅੰਤਰ-ਨਿਰਮਿਤ ਡਾਇਲਰ ਦੀ ਥਾਂ ਇੰਸਟਾਲ ਕਰਨ ਯੋਗ ਕਲਾਇੰਟ ਚਾਹੀਦਾ ਹੈ, ਤੇ ਅਕਸਰ ਇਹੀ ਇੱਕੋ ਕਾਰਨ ਹੈ ਕਿ PPTP ਗੱਲਬਾਤ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।
ਕੀ ਸੁਧਾਰਨਾ ਹੈ ਤੇ ਕੀ ਬਦਲਣਾ ਹੈ
ਫਾਰਵਰਡਿੰਗ ਤੇ MTU ਠੀਕ ਕਰਨ ਨਾਲ ਤੁਹਾਨੂੰ ਕੰਮ ਕਰਦੀ ਟਨਲ ਮਿਲਦੀ ਹੈ, ਰੱਖਣ ਯੋਗ ਨਹੀਂ। PPTP ਦਾ MSCHAPv2 ਪ੍ਰਮਾਣੀਕਰਣ ਸਾਲਾਂ ਤੋਂ ਹਮਲੇਯੋਗ ਹੈ, ਤੇ ਕੰਮ ਕਰਦੀ ਟਨਲ ਉਹ ਵਿਸ਼ਵਾਸਪੱਤਰ ਲੈ ਕੇ ਚੱਲਦੀ ਹੈ ਜੋ ਆਫ਼ਲਾਈਨ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਜੇ ਦੂਰ ਦਾ ਯੰਤਰ L2TP/IPsec ਜਾਂ OpenVPN ਚਲਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਸੁਧਾਰ ਨੂੰ ਤਾਰੀਖ ਵਾਲਾ ਅਸਥਾਈ ਉਪਾਅ ਸਮਝੋ।
ਫ਼ੈਸਲਾ ਇਸ 'ਤੇ ਆਉਂਦਾ ਹੈ ਕਿ ਦੂਰ ਦਾ ਸਿਰਾ ਕੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਤੇ ਪ੍ਰਬੰਧ ਕਿੰਨਾ ਚਿਰ ਟਿਕਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ਼ PPTP ਬੋਲਣ ਵਾਲਾ ਪੁਰਾਣਾ ਯੰਤਰ ਸੁਧਾਰ ਪਾਉਂਦਾ ਹੈ; ਕਲਾਇੰਟ ਇੰਸਟਾਲ ਹੋ ਸਕਣ ਵਾਲਾ ਸਭ ਕੁਝ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
ਟਿਕਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਲਾਗਇਨ ਨਹੀਂ ਸਗੋਂ ਵੱਡਾ ਟ੍ਰਾਂਸਫਰ ਝੱਲਦਾ ਹੈ, ਤੇ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਵੀ ਰਾਊਟਰ ਆਪਣਾ ਪ੍ਰੋਟੋਕੋਲ 47 ਨਿਯਮ ਰੱਖਦਾ ਹੈ। ਜੋ ਟਨਲ ਇੱਕ ਫਾਇਲ ਕਾਪੀ ਲੰਘ ਕੇ ਅਗਲੇ ਫਰਮਵੇਅਰ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਮਰ ਜਾਂਦੀ ਹੈ, ਉਹ ਕਦੇ ਪੂਰੀ ਨਹੀਂ ਹੋਈ ਸੀ।