PPTP ਜੁੜਦਾ ਹੈ ਅਤੇ ਫਿਰ Linux NAT ਪਿੱਛੇ ਅਟਕ ਜਾਂਦਾ ਹੈ: GRE ਸਹਾਇਕ

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

ਫਾਰਵਰਡ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ

ਪੋਰਟ-ਫਾਰਵਰਡ ਨਿਯਮ TCP ਜਾਂ UDP ਟ੍ਰੈਫਿਕ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਇਹ ਅਜਿਹੇ ਪੇਲੋਡ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ ਸੈਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਦੂਜੇ IP ਪ੍ਰੋਟੋਕੋਲ ਤੇ ਜਾਂਦਾ ਹੈ, ਅਤੇ PPTP ਠੀਕ ਇਹੀ ਕਰਦਾ ਹੈ।

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

ਨਿਯੰਤਰਣ ਲਈ TCP, ਡੇਟਾ ਲਈ GRE

ਕਾਲ TCP 1723 ਤੇ ਗੱਲਬਾਤ ਰਾਹੀਂ ਤੈਅ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਵਾਰ ਖੜ੍ਹੀ ਹੋਣ ਤੇ ਪੇਲੋਡ GRE ਵਿੱਚ, IP ਪ੍ਰੋਟੋਕੋਲ 47 ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕੋਈ ਪੋਰਟ ਨੰਬਰ ਨਹੀਂ ਢੋਂਦਾ। ਪੋਰਟਾਂ ਤੇ ਆਧਾਰਿਤ ਨਿਯਮ ਕੋਲ ਮਿਲਾਉਣ ਲਈ ਕੁਝ ਨਹੀਂ।

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

PPTP ਤੋਂ ਬਿਨਾਂ ਨੰਗੇ GRE ਨੂੰ ਅਜਿਹੀ ਦੁਬਾਰਾ ਲਿਖਤ ਦੀ ਲੋੜ ਨਹੀਂ, ਇਸ ਲਈ ਸਾਧਾਰਨ GRE ਟਨਲ ਉਸ ਰਾਊਟਰ ਵਿੱਚੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਸੇ ਰਾਹ ਤੇ PPTP ਕਲਾਇੰਟ ਲਈ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।

ਚਾਰ ਮਾਡਿਊਲ ਅਤੇ ਇੱਕ sysctl ਜਿਸ ਨੇ ਉਹਨਾਂ ਨੂੰ ਬੰਦ ਕੀਤਾ

ਦੋ ਮਾਡਿਊਲ ਫਰੇਮਿੰਗ ਸੰਭਾਲਦੇ ਹਨ, nf_conntrack_proto_gre ਅਤੇ nf_nat_proto_gre। ਦੋ ਹੋਰ ਕਾਲ ਪਛਾਣਕਰਤਾ ਸੰਭਾਲਦੇ ਹਨ, nf_conntrack_pptp ਅਤੇ nf_nat_pptp। ਆਖਰੀ ਨੂੰ ਲੋਡ ਕਰਨ ਨਾਲ ਬਾਕੀ ਨਿਰਭਰਤਾਵਾਂ ਰਾਹੀਂ ਆ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਮਾਡਿਊਲ ਸੂਚੀ ਵਿੱਚ ਚਾਰੇ ਦਿਖਣੇ ਚਾਹੀਦੇ ਹਨ।

ਪੁਰਾਣੀਆਂ ਹਦਾਇਤਾਂ 2.6 ਯੁੱਗ ਦੇ ip_ ਅਗੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਕਮਾਂਡਾਂ ਕੁਝ ਵੀ ਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਚੱਲਦੀਆਂ ਜਾਪ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਦੀ ਬਜਾਏ ਲੋਡ ਹੋਈ ਸੂਚੀ ਵੇਖੋ।

ਉਹਨਾਂ ਦਾ ਲੋਡ ਹੋਇਆ ਹੋਣਾ ਹੁਣ ਕਾਫੀ ਨਹੀਂ। Linux 4.7 ਤੋਂ net.netfilter.nf_conntrack_helper sysctl ਡਿਫਾਲਟ 0 ਹੈ, ਜੋ ਨਵੇਂ ਫਲੋ ਲਈ ਆਪਣੇ-ਆਪ ਸਹਾਇਕ ਨਿਯੁਕਤੀ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਰਾਊਟਰ ਵਿੱਚ ਹਰ ਮਾਡਿਊਲ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਕੁਝ ਵੀ ਅਨੁਵਾਦ ਨਾ ਹੋਵੇ। ਮਾਡਿਊਲ ਸੂਚੀ ਦੁਬਾਰਾ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਮੁੱਲ ਜਾਂਚੋ।

ਜਾਂ ਤਾਂ ਆਪਣੇ-ਆਪ ਨਿਯੁਕਤੀ ਦੁਬਾਰਾ ਵਿਸ਼ਵ ਪੱਧਰ ਤੇ ਚਾਲੂ ਕਰੋ, ਜਾਂ ਸਹਾਇਕ ਨੂੰ ਲੋੜਵੰਦ ਫਲੋ ਨਾਲ ਜੋੜੋ ਅਤੇ ਬਾਕੀ ਸਭ ਨੂੰ ਛੱਡ ਦਿਓ:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

ਦੂਜਾ ਵਿਕਲਪ ਤਰਜੀਹੀ ਹੈ। ਇਹ ਪੂਰੇ ਰਾਊਟਰ ਤੇ ਆਪਣੇ-ਆਪ ਨਿਯੁਕਤੀ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰਨ ਦੀ ਬਜਾਏ ਵਿਵਹਾਰ ਨੂੰ PPTP ਟ੍ਰੈਫਿਕ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ।

ਪੋਰਟਾਂ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰੋਟੋਕੋਲ ਖੋਲ੍ਹਣਾ

1723 ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਪ੍ਰੋਟੋਕੋਲ 47 ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। firewalld ਤੇ ਕਲਾਇੰਟ ਵੱਲ ਵਾਲੇ ਜ਼ੋਨ ਵਿੱਚ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਆਗਿਆ ਦਿਓ। ਸਾਧਾਰਨ iptables ਤੇ ਇਨਪੁਟ ਚੇਨ ਵਿੱਚ gre ਪ੍ਰੋਟੋਕੋਲ ਸਵੀਕਾਰ ਕਰੋ।

ਫਿਰ ਦੋਵੇਂ ਪਾਸੇ ਕੈਪਚਰ ਕਰੋ। ਕਲਾਇੰਟ ਛੱਡਣ ਵਾਲੇ ਪੈਕਟਾਂ ਦੇ ਜਵਾਬ ਨਾ ਆਉਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵਾਪਸੀ ਦਾ ਰਾਹ ਫਿਲਟਰ ਹੈ, ਅਤੇ ਇਹ ਰੱਦ ਕੀਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਤੋਂ ਵੱਖਰੀ ਖਰਾਬੀ ਹੈ।

ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਆਕਾਰ ਦੀ ਸੀਮਾ

GRE ਹੈਡਰ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਅੰਦਰਲਾ PPP ਹੋਰ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਲਿੰਕ 1500 ਤੋਂ ਕਾਫੀ ਘੱਟ MTU ਦੱਸਦੀ ਹੈ। ਛੋਟੇ ਜਵਾਬ ਲੋਡ ਹੁੰਦੇ ਹਨ ਅਤੇ ਵੱਡੇ ਅਟਕ ਜਾਂਦੇ ਹਨ, ਜੋ ਪਹਿਲੀ ਸਮੱਸਿਆ ਹੱਲ ਹੁੰਦਿਆਂ ਹੀ ਦਿਖਣ ਵਾਲੀ ਦੂਜੀ, ਅਸੰਬੰਧਿਤ ਸਮੱਸਿਆ ਵਰਗਾ ਲੱਗਦਾ ਹੈ।

ਕਲਾਇੰਟ ਦੇ PPP ਅਡੈਪਟਰ ਤੇ MTU ਪੜ੍ਹੋ ਅਤੇ ਰਾਊਟਰ ਦੀ ਆਪਣੀ ਗਣਨਾ ਨਾਲ ਮਿਲਾਓ ਕੁਝ ਕੰਮ ਕਰਨ ਤੱਕ ਸੰਖਿਆਵਾਂ ਘਟਾਉਣ ਦੀ ਬਜਾਏ। ਪੂਰੇ ਆਕਾਰ ਦੇ ਪੈਕਟ ਬਾਹਰ ਜਾ ਕੇ ਕੁਝ ਵਾਪਸ ਨਾ ਆਵੇ ਤਾਂ ਉਹ ਅਨੁਵਾਦ ਵੱਲ ਨਹੀਂ, ਉਸ ਸੀਮਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਰਾਹ ਦੀ ਮੁਰੰਮਤ ਵਰਤੋਂਕਾਰ ਨੂੰ ਕੰਮ ਤੇ ਲਿਆਉਂਦੀ ਹੈ, ਅਤੇ ਇਸ ਨਾਲ PPTP ਚੰਗਾ ਵਿਕਲਪ ਨਹੀਂ ਬਣਦਾ। MS-CHAPv2 ਅਤੇ RC4 ਬਹੁਤ ਪਹਿਲਾਂ ਹੀ ਬਾਹਰ ਹੋ ਚੁੱਕੇ ਹਨ, ਇਸ ਲਈ ਮਾਡਿਊਲ ਲੋਡ ਕਰਨ ਨੂੰ ਅਸਥਾਈ ਸੁਧਾਰ ਮੰਨੋ ਅਤੇ ਸੰਭਾਲੇ ਹੋਏ ਪ੍ਰੋਟੋਕੋਲ ਵੱਲ ਜਾਣ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।